January 18th, 2023

Server Workgroup Updates
1

Attendees: @adam-fowler, @davmoser, @lukasa, @jdmcd, @kmahar, @patrick, @0xTim, @tomerd, @FranzBusch, @Joannis_Orlandos, @graskind

Action Items

  • All discuss 2023 goals as first item of next meeting
  • All: reformulate the guidelines for adopting async/await and Swift concurrency together at next meeting
  • @FranzBusch to start a doc explaining what a good server API looks like, what happens in a run(), how to gracefully shut down, how to interact with Unix signals, how to compose with other servers, etc.
  • @ktoso and @adam-fowler to audit SSWG incubated projects to see if they 1) offer async APIs 2) Use async internally
  • All: take a look at and contribute to the thread @FranzBusch started about missing components of the Swift server ecosystem
  • @ktoso to post review thread for Cassandra client
  • @davmoser Check out possibly contributing a blog post about the AWS examples / the async adoption experience for them
  • @graskind to finish updating swift evolution for property wrappers in protocols
  • [carry over] @tomerd continuing work on getting community survey published
  • [carry over] @graskind SPM plugins for fluent 5
  • [carry over] @tachyonics: set up middleware meeting
  • [carry over] @0xTim to investigate slim containers based on Canonical's work
  • @tomerd to ask Saleem if he's interested in attending a meeting
  • [carry over] @tomerd and @patrick to work out moving Swiftly to swift-server org and getting CI setup
    • waiting on patrick to give the go-ahead, after some last polish

Discussion

NIO 3 goals

  • Things we will definitely do:

    • Major version 3 of NIO one way or another
    • At minimum dump deprecated API surface
    • Drop older Swift version compatibility
    • Fix Sendable problems we will likely have

  • Things we would like to do:

    • Finalize the NIO async Channel story, pivot to that as the principal API surface
      • There are still some wrinkles in the programming model there though
      • NIO3 allows us to iron them out, but it potentially exposes a big change to Channel
      • NIO Channel today exposes the inbound/outbound types of the pipeline up front, but there are many cases where when you call bind you might not know what types those will be (e.g. situation where you might do HTTP/1 or HTTP/2, or any delayed protocol negotiation)
      • The API change for this hasn't been fleshed out yet
    • Drop duplicative types from our API

Do the next major versions of Vapor/NIO/other libraries need to be tied to Swift 6 then?

  • Vapor:

    • Vapor is releasing a minor version in the next or month or two that deprecates the future-based APIs which should push people to async
    • 95% of people can write all their code when using async-await, not many edge cases
    • We could do a Vapor 5 now, but might need to do another major release if NIO3 is released, and then maybe another for Swift 6

  • Overall, user-facing library ecosystem (e.g. web frameworks, database drivers) should be orienting towards async without having to wait for Swift 6 by introducing async APIs and deprecating future-based APIs.

    • There are no real blockers to doing this.

  • What might need to wait for Swift 6 + NIO3 is rewriting library internals to adopt concurrency. Until then, its important libraries provide an async API so that end users can adopt it, even if the internals are futures based.

    • There are benefits of adopting concurrency internally early though
      • Helps provide feedback for the development of Swift 6
      • Tests async API, breaks in the future will be smaller and adoption easier

  • Over the next weeks or months, this group should figure out if there are certain existing APIs they can't express or require a ton of boilerplate to do so when using async, and we can take that feedback to the language team to make the transition for the greater ecosystem easier.

  • Action item: @ktoso and @adam-fowler to audit SSWG incubated projects to see if they 1) offer async APIs 2) Use async internally

Service lifecycle replacement in async world?

  • How do we expect frameworks to expose their async APIs so that they all compose together?
    • Hopefully @ktoso's work on task pools will help
  • Service lifecycle doesn't translate to async that well, maybe we can ditch it?
  • If it is necessary, we'll make a 2.0 refactor.
  • Action item: Franz to start a doc explaining what a good server API looks like, what happens in a run(), how to gracefully shut down, how to interact with Unix signals, how to compose with other servers, etc.
    • Service developers and library maintainers alike can follow this
  • Action item: All to reformulate the async adoption guidelines together at the next meeting

AWS Swift examples

6 Likes