January 18th, 2023

[patrick]

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

• AWS has a number of examples they're going through and updating to use async / Swift concurrency
  • GitHub - aws-samples/aws-lambda-with-aws-sdk-for-swift: This sample application demonstrates using the AWS SDK for Swift in a AWS Lambda function. It uses Docker to compile and package the function into a Docker image. It then uses the AWS Cloud Development Kit (AWS CDK) to deploy the image and create the Lambda function in AWS.
  • GitHub - aws-samples/aws-serverless-fullstack-swift-apple-carplay-example: This application demonstrates a full-stack Apple CarPlay app that uses Swift for both the UI and the backend services in AWS. The app accesses Lambda functions written in Swift and deployed from Docker images. The app accesses Amazon Location Service and a 3rd party weather api to display information in the vicinity of the user.
  • Swift.org - Deploying to AWS Lambda using the Serverless Application Model (SAM)
  • Swift.org - Deploying to AWS with Fargate, Vapor, and MongoDB Atlas
• The website work group just published guidelines for community blog posts, this could be great material for that.
  • Anyone in the community who's interested in sharing knowledge / gaining visibility is also encouraged to contribute blog post material
  • Action item: @davmoser to check out the guidelines to see if the examples async adoption would make sense for a blog post