Async/await and the future of Vapor

Hi all,

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.

Vapor 4

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.

Vapor 5

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 EventLoopFuture references - 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 EventLoopFuture types 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

70 Likes

This post was flagged by the community and is temporarily hidden.

This all mostly sounds great! Thanks for the writeup and clarification. One question/point on my part:

I would definitely advocate for this to be strictly opt-in/an additive feature. In my mind it's not acceptable to meaningfully degrade performance for the sake of a different declaration syntax. I'd be perfectly happy with keeping the current routing infrastructure as-is and introducing this as an optional declaration syntax on top of it (i.e. your last suggestion).

7 Likes

I've been trying out the async/await Vapor branch and it makes using the framework much easier to pick up and reason about than EventLoopFutures. Betting this will help a lot with adoption! For Vapor 5 I think switching to the new concurrency features should improve readability and debuggability of the codebase as it would be possible to get rid of some the hacks that were necessary in a pre async/await Swift world. Overall very excited about the future of Vapor, Thanks Vapor Team!

7 Likes

I’ve been following the async/await PR, super excited for that to be available. Great work!

I’ll throw a +1 here, as well - it’s a super helpful technology, and I think the ease of integration with other stacks that it offers would be a big benefit.

Thanks to the Vapor Core Team for all your hard work, it’s much appreciated!

2 Likes

First of all, thanks for all the work with Vapor 4 and the future support of Swift 5.5 concurrency.

Are there any project to make drivers for Fluent to support commercial databases like Oracle or MS SQL Server?

I'm in love with Vapor and we have many clients in production so happy with its performance and versatility.

Thanks in advance.

There have been several discussions about drivers for these but I'm not aware of any implementations. Wrapping any C drivers will work otherwise you'd need to build it yourself.

If there were NIO based drivers for MSSQL or Oracle we could wrap them for Fluent but for now we're focusing on open source DBs

Sounds interesting. Maybe I could try to implement a NIO driver. Thanks for your reply.

Hurray for all these changes. Having just started a large API server in Vapor 4 (which I am loving). The futures can be painful at first. Can't wait for async/wait and OpenAPI.

I am going to guess this is a 2022 Swift 6 release? No 4.5 with async/wait?

@scottandrew Vapor 4 will get async/await APIs soon as mentioned here

2 Likes

While my work on it has gone stale, I have made quite a bit of progress on an implementation of the TDS (Tabular Data Stream) protocol, the underlying wire protocol for SQL Server Client/Server communication. You can find my implementation here.

My recent efforts are in introducing a large refactor to match an implementation similar to that of the changes that @fabianfett had made to recently to the Postgres driver.

I’m hoping I can make meaningful progress here soon.

2 Likes

Thank you for the update! I’ve been a bit out of the loop when it comes to Vapor’s async/await adoption, but will there be any performance hits that warrant extra considerations once the branch is merged?

Thanks a lot for the update! Great news!

The performance difference is still a bit unknown at the moment and changes depending on platform etc. There will likely be a small hit until custom executors is implemented but the benefits of async/await will outweigh it for the majority of people

2 Likes

This is great news! I think the async/await APIs will make Vapor a lot simpler and more approachable for iOS devs :slight_smile:

1 Like
Terms of Service

Privacy Policy

Cookie Policy