June 22nd, 2022

Server Workgroup Updates
1

Attendees

Previous meeting reviews

WebAuthn

  • WebAuthn library - @0xTim to post once PoC finished.
  • @tachyonics mentioned that creating a generic middleware type for this would be helpful.
  • @fabianfett mentions that a standard middleware really helped the NodeJS ecosystem.
  • @ktoso mentions tracing could make the most of this as well.
  • @tachyonics HTTP Client PoC has a generic middleware concept that we could use.
  • @fabianfett asks if we should start with client or server middleware to flesh this out. It was agreed to start with the client. Will discuss more in the HTTP client meeting.
  • @fabianfett and @tachyonics will lead this.

Property wrappers

  • @0xTim and @graskind working on post.
  • @jdmcd mentions they saw a 100x improvement when dropping below Fluent to SQLKit for performance limiting code.
  • @0xTim mentions the problems are a mixture of reflection and not being able to require them in protocols.

Swiftly

  • @adam-fowler and @Patrick are talking to Mishal and discussions are underway about where to put it
  • @patrick will start work in a private repo to begin with until we work out where it should live

Agenda

VSCode Blog Post

AWS Server-side Swift Content

  • @davmoser role is evangelism, asks if the SSWG the right place to have a backlog of items for content
  • We have a list of issues of the SSWG guides for things that would be good to see written about
  • [AI] Tim to create some AWS issue - Issues are here
  • The swift.org site will end up consuming the guides

How to make using Swift on AWS easy

  • Triggered by @tachyonics post What would help you use Server Side Swift with AWS
  • What things do we need to make deployments etc really simple (similar to a Heroku push)
  • The obvious solution is CDK, but there’s a barrier as Typescript is the language, seems weird for a Swift developer
  • Potential for using the AWS Swift SDK
  • Network access for SwiftPM plugins will eventually come but for now requires disabling the sandbox. Will be required for any deployment plugin
  • Potential to build plugins to make deployment easy
  • @tomerd has a PoC Docker plugin for wrapping a Swift application into a Docker container
  • @tachyonics team has a Swift application to package a Swift project in a Docker container
  • Ideally any plugin/example should live in the Swift server GH repo
  • @ktoso has pointed out the Scala packaging plugin which is one of the most popular plugins in the ecosystem, would be a valuable thing to have in the ecosystem - GitHub - sbt/sbt-native-packager: sbt Native Packager
  • [AI] @tachyonics to find out what can be shared as a basis to start - https://github.com/swift-server/swift-aws-deploy-poc

Swift.org guides

  • [AI] @0xTim to find out where to put the SSWG guides as a start
5 Likes
2

@0xTim @graskind I think a standardized KeyPathReflection/KeyPathIterable which allows for the retrieval/iteration of the properties for a given struct/class would be very useful. I believe this would be valuable for SQL model encoding/decoding performance especially if cached. @Alejandro helped me to get his and @rxwei's experimental KeyPathReflection library working with Swift 5.6/5.7 a while ago. I've created a PR to get KeyPathReflection working on Swift 5.6 & 5.7. I've been using it for some SQLKit extensions that allow me to get the static properties names of a given struct and use them as column names in select queries. Wondering if we could look into this further for better Fluent performance.

3

Unfortunately, it's of limited value in terms of Fluent 4; there are numerous design flaws (or, at the very least, design choices that were made due to the limitations of Swift at the time) that would prevent it from realizing more than minimal benefits from the KeyPathReflection work (though I hasten to add that that work is excellent!).