Server Side Swift - AppBuilders 2017

jensravens.com / AppBuilders 2017
Server Side Swift
Why it’s awesome and
why you should care.
Jens Ravens

😱

Who is this guy?

Who is this guy?
(aka the shameless self promotion part)

Jens Ravens
Developer at nerdgeschoss, a mobile ﬁrst dev agency for sophisticated software. We
help startups and medium businesses to build awesome stuff.

Jens Ravens
50% iOS / macOS using Swift
50% Web / API using Ruby on Rails

Jens Ravens
Also I blog about Swift stuﬀ on jensravens.com and organize
the monthly swift.berlin meetup.

What I am going to talk about…
a short introduction to http, the internet and everything else
abstracting the server implementation from request handling
Model, View, Controller, Router, Storage
why Swift on the server might actually be a good idea
the current state of server side Swift

Why Swift on the server might actually
be a good idea.
🚀 🤓
speed developer happiness

Raw Performance. 🚀
Ryan Collins, August 2016

So server side Swift is screaming fast.
It gives you more bang for the buck.
But here is a well kept secret…
I just don't care.

A look at last month’s spendings.
Server Costs
2 %
Oﬃce
11 %
Salaries
87 %

A look at last month’s spendings.
faster development = more revenue

Swift is fast enough. We should focus on
developer productivity instead.

A short introduction to http, the internet and
everything else.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 7897
Connection: Keep-Alive
<!DOCTYPE html>
<html lang="en">
Browser
http://jensravens.com
DNS Server
;; ANSWER SECTION:
jensravens.com. 3600 INA 37.120.178.83
37.120.178.83
Server
Load Balancer
App App
GET / HTTP/1.1
Host: jensravens.com
User-Agent: curl/7.43.0
Accept: */*

Hey, that’s just some plain text over tcp!
Yep, you’re right.

Get a Request, give a Response.
public protocol Response {
var headers: [String: HeaderType] { get }
var code: StatusCode { get }
var content: Streamable { get }
}
public protocol Request {
var method: HTTPMethod { get }
var path: String { get }
var params: [String:String] { get }
var headers: [String:String] { get }
var format: Format { get }
var body: Streamable? { get }
}
public protocol Streamable {
var stream: Void -> NSData? { get }
}

But isn’t this the same for every app on every server?
Yep, you’re right.

Abstracting the server implementation
from request handling
Ruby: Rack.
Every app is just a function transforming request to response.

Abstracting the server implementation
from request handling
Meet the Open Swift Standards.
https://github.com/open-swift
Open Swift Standard
Server Implementation
Your awesome App
The Internetz
and the Swift Server APIs.
https://swift.org/server-apis

Structuring Web Applications in Swift with MVC-RS
*
*Term shamelessly copied from a presentation
by Greg Lhotellier at SwiftConf 2016

public typealias Controller = Request throws -> Response
let myApp: Controller = { request in
return Response(code: 200, headers: [:], content: "Hello World")
}
Get a Request, give a Response: the Controller.

Making things pretty: Rendering Views.
public protocol View {
func render() throws -> Streamable
func render() throws -> Response
var contentType: Format { get }
}

public struct JSONView: View {
public var contentType: Format { return .JSON }
let contents: AnyObject
public init(_ contents: AnyObject) {
self.contents = contents
}
public func render() throws -> Streamable {
return try NSJSONSerialization.dataWithJSONObject(
contents, options: .PrettyPrinted)
}
}

Models and Persistence: Storage.
protocol Repository {
associatedtype Element
func find(index: Int) -> Element
func query(conditions: Predicate) -> [Element]
}
struct Post {
let id: Int
var title: String
var content: String
}
let post = try postsRepository.find(request.params[“id"])
let attributes = ["id": post.id, "title": post.title]
return JSONView(attributes)

let myApp: Controller = { request in
json = JSONView(["message":"Hello World #{request.params["id"]}"])
return Response(code: 200, headers: [:], content: try json.render())
}
Where to go next: the Router.
public final class Router {
public func get(path: String, app: Void -> Controller)
public func post(path: String, app: Void -> Controller)
…
public func controller(request: Request) throws -> Response
}
let router = Router()
router.get("messages/:id") { myApp }
serve(router.controller)

MVC-RS in Review
Database External Webservice
Repository RepositoryRepository
Controller Controller
Model View Model View
Router

Some Observations.
Models don’t inherit or conform to anything.
Controllers can call other controllers (Middleware).
Client and server architecture are pretty similar which allows code sharing.
Routers are also controllers and therefore can be nested.

The current state of server side Swift.

https://vapor.codes

http://www.kitura.io

My personal wishlist.
be explicit - but don’t be verbose
more projects conforming to Open Swift Standards Server APIs
don’t just imitate other frameworks - use Swift’s
modern and type safe features
a framework that comes totally conﬁgurable, but batteries included

🤓
happy developer

Thank you.
Jens Ravens / @jensravens

Server Side Swift - AppBuilders 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Server Side Swift - AppBuilders 2017

Similar to Server Side Swift - AppBuilders 2017 (20)

More from Jens Ravens

More from Jens Ravens (9)

Recently uploaded

Recently uploaded (20)

Server Side Swift - AppBuilders 2017