Now that Swift 5.5 is released and we're getting several questions about async/await in Vapor we thought we'd put a post up with our next steps and plans for the future.
When there's an Xcode release that contains a macOS SDK to allow us to test and run async/await code locally we'll merge the async PR to add it to Vapor. We don't want to do this sooner to avoid any confusion. To be clear, Vapor 4 will get async/await APIs. These will be alongside all the current APIs to allow you to slowly migrate your code as you want. We're currently working on making sure the docs, Fluent and any other APIs have async versions to make switching easy. To start with we’ll release all the high level stuff and then work over the coming months to add it to the lower level APIs and packages. Several people have already been running tests using the branches and things seem good so we're excited to see even more interest in server-side Swift!
We're also keeping an eye on tracing and logging and their interactions with task local values to make sure we can integrate them properly.
The SSWG have published guidelines for migrating to Swift’s new concurrency model. We know that there will be coming breaking changes in Swift with Swift 6 to ensure safety when using concurrency and others. Along with custom executors and a potential SwiftNIO 3.0 release we'll take the opportunity to release the next major version of Vapor, Vapor 5. We don't have any timescales for this yet as a lot depends on our dependencies. However we are going to set some goals and would like input from the community on them (these are all obviously subject to change):
- Remove all
EventLoopFuturereferences - Vapor 5 will be async/await throughout and our use of SwiftNIO will be an implementation detail to our users.
- Remove all exports in Vapor - we currently export a number of dependencies. This makes sense for the packages that integrate our *-Kit packages with Vapor so you only need to import Fluent for example and not FluentKit as well. This was partly necessitated by exposing
EventLoopFuturetypes but has also caused us several headaches. So Vapor 5 itself will not export everything and our other packages will only export packages we control
- Commit to supporting Vapor 5 for 2 years - Vapor 3 was out for 2 years, and Vapor 4 will likely see a similar timetable but we're aware that there's a perception things change a lot and we want to ensure some stability for the community to help people plan
- Migrate to DocC - we think DocC could be interesting and assuming the open source plans pan out we'll likely use it
- OpenAPI support - this is a personal one for me, but I'd like to see first class support to make it easy to integrate
- Related, we're investigating declarative routing. This would make integrating OpenAPI relatively simple but the initial investigations show it introduces a big performance hit. However it could change or be offered as an option
- @graskind will post a follow up on the plans for Fluent 5
If you have any other ideas, let us know!
The Vapor Core Team