Week 15
News
Weekversary of Vapor 3 🎉🎉🎉. This week has been particularly interesting because of the amount of articles and tutorials the Vapor Community have contributed, Vapor now has its own thread at the Swift Forums, and most importantly, Vapor 3.1, yes, you read it right, Vapor’s development team is restless already thinking on 3.1, awesome, is not it?
New Features
Add a non-variadic ‘on’ method to router
Adds a non-variadic overload to router.on(...) to allow users to crete routes with arrays of parameters.
The following snippet creates a Route at the provided path using an HTTP method. This route will return "Hello, world" to GET requests to /hello/world
router.on(.GET, at: ["hello", "world"]) { req in
return "Hello, world!"
}
You can use anything that conforms to PathComponentsRepresentable to create the path, including type constrained parameters.
router.on(.GET, at: ["users", Int.parameter]) { req in
let id = try req.parameters.next(Int.self)
return "User #\(id)"
}
Model cleanup (more than that)
- Cleanup the session persist protocols
- Reduce usage of model to where necessary, adding behavior via extensions
- Allows middlewares to be composed. Fixing vapor/auth#34
Export Crypto in Authentication
Export Crypto in Authentication so using things like the BCryptDigest for setting up a password verifier don’t require an import Crypto
NIO
Implement lazy selector registration
Motivation:
Previously we would eagerly register any fd with the selector (epoll/kqueue) which works well with kqueue. With epoll however, you’ll get EPOLLHUP immediately if you supplied a socket that hasn’t had connect/bind called on it. We got away with this because we took quite a bit of care to always make sure we call connect/bind pretty much immediately after we registered it. And crucially before we ever asked the selector to tell us about new events.
Modifications:
Made selector registration lazy (when we try activating the channel by calling connect/bind)
Result:
The user can now register and connect whenever they feel like it, fixes apple/swift-nio#380
Add support for compiling and running NIO on Raspberry Pi 32-bit
Motivation:
Pretty much every developer in the world want to run MicroExpress applications on Raspberry Pi K8s clusters. The unfortunate precondition to that is getting NIO compiled for RaspberryPi. This PR makes it work.
Thanks go to @chnmrc for providing a Swift 4.1 Raspi build, also available via a DockerHub: helje5/rpi-swift.
Modifications:
Two main changes:
- Timestamps used to be stored as Int, this needs to be an explicit Int64 to provide the necessary value range for ns values
- Some hardcoded pointers like 0xdeafbeef got mapped to Int values, but Int32 can’t represent 0xdeadbeef. Needs to be UInt32 to capture the full deadness.
Result:
NIO compiles on Raspi 3, 32-bit Ubuntu. I tried the Echo Server, which seems to work, and also the HTTP sample Server, which also seems to work.
P.S.: This should also allow you to run NIO on AppleWatch, which is 32-bit too.
Community Contributions
Add support for SSL-enabled Postgres servers
- Adds an optional tlsConfiguration property to PostgreSQLDatabaseConfig. An attempt to open an SSL connection will only be made if this is non-nil
- Adds the handshake required by PostgreSQL to check for SSL support
- Uses NIOOpenSSL to add a OpenSSLClientHandler to the PostgresSQLConnection channel pipeline using the aforementioned tlsConfiguration property
- Updates contributing_bootstrap.sh to spin up a second container using a new postgres-ssl Docker image, which creates a self-signed certificate to enable ssl on the Postgres container
- Updates PostgreSQLConnectionTests to add a SSL connection test
Rename makeResponse to response
Renames req.makeResponse() to req.response()
Add Data responses and TypedDataResponse
In some cases, you may want to just return raw Data
Feature/infer auth type from context
This PR allows
secured.get("me") { request -> U in
try request.requireAuthenticated()
}
instead of
secured.get("me") { request -> U in
try request.requireAuthenticated(U.self)
}
Same for the other authentication methods.
Remove unnecessary Model conformance on Authenticatable
Authenticatable types no longer need to be Models
Tagged releases
- Vapor 3.0.2
- HTTP 3.0.5
- Redis 3.0.0 RC 2.6
- Auth 2.0.0 RC4
- URL-Encoded Form 1.0.3
- WebSocket 1.0.1
- Crypto 3.1.2
- PostgreSQL 1.0.0 RC 2.2
Articles
Vapor 3.0.0 release article
Brought to you by Vapor’s development team
Server Side Swift frameworks comparison
A bit old, given the fact everything changes really fast (Feb)
Server Side Swift Frameworks Comparison
Transforming from Vapor 2 to Vapor 3
Brought to you by @calebkleveter
CRUD using Leaf
Brought to you by @MartinLasek
Routing and Fluent
Brought to you by @calebkleveter
Deploying Vapor 3 on Cloud Foundry
Brought to you by @idev4u
Deploying Vapor 3 in Cloud Foundry
HTTP Basic Auth with Vapor 3
Brought to you by @anapaix
Getting started with Vapor 3 (Updated)
Brought to you by Paul Hudson
Want to know more or get inspired?
- Check out what we are working on now. You might see something you can collaborate with Issues
- Check out more Vapor awesomeness Awesome Vapor
- Some more Vapor learning material Vapor School
- Vapor’s Core team had published an early access book on Vapor through RW here
- Paul Hudson had also updated his Server Side Swift with Vapor book here
- Also the RW’s Vapor Video Course Server Side Swift with Vapor - Video Course
- Vapor Forum Vapor Forum
- Vapor Forum @swift.org Vapor@swift.org
Take action
There are many ways you can contribute with Vapor
- Star the project in GitHub
- Follow us on Twitter
- Follow us on Medium
- Become a backer
- Become a sponsor
- Come and talk to us