SSWG updates
Since the last time we gave a major update on the SSWG, a lot has happened. First of all, we were very happy to welcome MongoDB and Amazon to the SSWG, represented by
- Kaitlin Mahar (MongoDB)
- Simon Pilkington (Amazon)
- Todd Varland (Amazon)
Kaitlin, Simon and Todd officially joined on the 24th June last year.
Further changes to the SSWG team came with the membership terms for Tanner Nelson & Logan Wright (both Vapor) as well as Tom Doron & Johannes Weiss (both Apple) coming to term in October last year. SSWG membership term is capped at 2 years per the initial announcement at try! Swift New York City October 2018.
Hence, Apple & Vapor both proposed two members respectively which were up for (re-)election in December 2020. After confirmation of the candidates, the new representatives for Vapor & Apple are:
- Gwynne Raskind (Vapor, first term)
- Tim Condon (Vapor, first term)
- Konrad Malawski (Apple, first term)
- Johannes Weiss (Apple, second term)
Tom Doron will continue to observe the SSWG meetings for the Swift Core Team.
This a good opportunity to say a huge thank you to Tanner & Logan for their representing Vapor and the SSWG since day one. We also want to thank IBM who decided to leave the SSWG in December 2019 for their leadership and contributions over the years.
Last year's goals
To start the SSWG's 2020 year, we published a Special Update which -- much like this one -- summarised the past year and set out goals for the next year.
Due to changes in priorities and membership, the interest in Zookeeper, Cassandra, and Kafka seems to have faded a little which meant that the SSWG spend more time focussing on the remaining goals, which led to a very successful period. Work for each of the goals is either completed or well underway. The following section is an introduction to the new projects on SSWG package index and insight into the work that is still in progress.
Completed
gRPC Swift
- Accepted: 19th February 2020
- Authors: Daniel Alm (Timing), George Barnett (Apple), Tim Burks (Google), Michael Rebello (Lyft)
- Code: github.com/grpc/grpc-swift
gRPC Swift provides official gRPC support for clients & servers written in Swift.
Swift Crypto
- Accepted: 4th March 2020
- Author: Apple (@apple)
- Code: github.com/apple/swift-crypto
Swift Crypto is an open-source implementation of a substantial portion of the API of Apple CryptoKit suitable for use on Linux platforms. It enables cross-platform or server applications with the advantages of CryptoKit.
OpenAPIKit
- Accepted: 29th April 2020
- Author: Matt Polzin
- Code: github.com/mattpolzin/OpenAPIKit
A library containing Swift types that encode to- and decode from OpenAPI Documents and their components.
MongoSwift
- Accepted: 13th May 2020
- Author: MongoDB (@mongodb)
- Code: github.com/mongodb/mongo-swift-driver
The official MongoDB driver for Swift applications on macOS and Linux.
Swift AWS Lambda Runtime
- Accepted: 24th June 2020
- Author: Fabian Fett & Tomer Doron
- Code: github.com/swift-server/swift-aws-lambda-runtime
Swift AWS Lambda Runtime is designed to help Swift developers build serverless functions for the Amazon Web Services Lambda platform.
Backtrace
- Accepted: 29th July 2020
- Author: Ian Partridge
- Code: github.com/swift-server/swift-backtrace
This Swift package provides support for automatically printing crash backtraces of Swift programs.
Service Lifecycle
- Accepted: 2nd September 2020
- Author: Tomer Doron
- Code: github.com/swift-server/swift-service-lifecycle
Swift Service Lifecycle provides a basic mechanism to cleanly start up and shut down the application, freeing resources in order before exiting. It also provides a Unix signal-based shutdown hooks.
Soto for AWS
- Accepted: 12th November 2020
- Author: Adam Fowler
- Code: github.com/soto-project/soto
Soto is a Swift language SDK for Amazon Web Services (AWS), working on Linux, macOS and iOS. This library provides access to all AWS services. The service APIs it provides are a direct mapping of the REST APIs Amazon publishes for each of its services. Soto is a community supported project and is in no way affiliated with AWS.
In-progress
Distributed Tracing
Distributed tracing allows to observe how code runs through multiple services. It all starts with the services annotating their work with some metadata which allows the individual pieces of information to be pieced together into one trace. The distributed tracing work (which started in the Google Summer of Code 2020) led to a fully functional package swift-distributed-tracing which comes with support for OpenTelemetry, Zipkin, Jaeger and AWS X-Ray. The work was lead by Google Summer of Code student Moritz Lang and mentor Konrad Malawski.
Konrad also leads the Task Local Values feature which is a part of Swift Concurrency. Task Local Values will tremendously simplify the code work required to support tracing and therefore Moritz & Konrad decided to delay the SSWG pitch until Task Local Values are part of Swift. So whilst you can adopt the swift-distributed-tracing API today, it is recommended you wait until Swift Concurrency is released which will then allow you to adopt distributed tracing without major API changes all throughout your package's APIs.
Database drivers
Both SQLiteNIO & MySQLNIO are fully functional and are currently active SSWG pitches. This is to say that you can start using them today! Any feedback is of course very much welcomed as part of the SSWG pitches and the upcoming proposals!
Connection pools
Several SSWG members and other interested developers from the community are thinking about a more general and reusable connection pool API package. Some preliminary discussion has taken place already. Stay tuned for updates and reach out if you have interest in this work!
Deployment guides
To make getting started with Swift on the server easier, we set up to create a number of deployment and production guides. A number of guides are already available but we are continuing to increase coverage of some further scenarios that Swift server developers may likely find themselves in. Stay tuned for updates!
Updates to the incubation levels
In accordance with the SSWG's Graduation Criteria, the maturity levels are reviewed at a regular cadence. We are happy to announce that in the last review a number of packages have been voted into a higher maturity level. The packages which have been upgraded to a higher level are:
- SwiftLog, to graduated
- SwiftMetrics, to incubating
- PostgresNIO, to incubating
- AsyncHTTPClient, to graduated
- APNSwift, to incubating
- SwiftCrypto, to incubating
- Backtrace, to incubating
2021 Goals
We believe that the SSWG's incubation program makes a very valuable contribution to the ecosystem and therefore we will of course be continuing and expanding this work. To that end, the SSWG role is to encourage and help guide community initiatives from ideas to production ready tools and libraries. This is to say that if you already have or are thinking of building a package that brings utility to the server community, please discuss, pitch, and propose it to the incubation process.
Beyond the incubation process, the SSWG will focus on three key areas in 2021:
- Moving the ecosystem to Swift's new concurrency model
- Tooling
- Documentation
A few more details on what the SSWG decided to be some of the core deliverables follow. And again, this is a community effort so if you have interest in these areas, please do reach out via the Swift Forums or however you see fit.
Moving the ecosystem to Swift's new concurrency model
One of the important functions of the SSWG is to ensure that packages work together well. With Swift's new concurrency model coming in Swift 5.5 we expect to see a lot of (fantastic!) changes to the APIs and we'd like to help to make this transition as swift & smooth as possible.
To start with, we'd like to see the lower level libraries updated. It's worth pointing out that this effort is not limited to creating APIs that work well with async/await. It includes all of Swift Concurrency such as structured concurrency, actors, distributed tracing, and more!
Apart from updating the incubated libraries we also want to publish guides that hopefully help all package authors with suggestions on how to migrate APIs to Swift Concurrency. And lastly we will listen to package authors and see what other resources we can provide to help. And once more, this is a community effort. We do realise that we are all beginners in Swift Concurrency and we can't get everything right which is to say that your feedback and help will be invaluable.
Tooling
On Apple platforms, getting started with the Swift programming language, including a fully featured IDE is a single step process: Open the App Store and install Xcode.
On other platforms, Swift is harder to get started with. There are too many steps involved to get to the same fidelity on Linux or Windows.
For examples, on non-Apple platforms Swift should be easier to install. We could help users with tools similar to rustup or Haskell Stack as well as .deb/ .rpm/... packages that can be installed using a Linux distribution's package installer.
Similarly, when it comes to IDE, editor, and CI system support we would like to make significant forward progress this year. If possible we'd like to reduce the number of steps/clicks to go from nothing to a working system. And for the remaining, necessary steps we would like to offer consistent documentation that's easy to find.
Whatever your favourite IDE, editor, or CI system may be, we think that Swift should be supported well. We'd love to work with you on improving the situation, so please reach out through the Swift Forums if you are willing to help! As examples, some areas we thought of are the availability of good plugins (for editors/IDEs), recipes (for CI systems), syntax highlighters, and of course guides on how to get up and running with Swift in your environment. But in the end what matters most is what you -- our community -- require and can help with.
Lastly, with the introduction of Apple Silicon, AWS Graviton, and the popularity of platforms such as the Raspberry Pi, the CPU landscape is less homogenous than it was a few years ago. This means that new workflows need to become possible and made simple. It's no longer an edge-case to develop on a machine with the ARM64 (also known as aarch64) instruction set but deploy to Intel x86-64 in production. Possible options to look into here are cross-compilation as well as running "foreign" docker images.
Improve documentation
The documentation for many parts of Swift on Server ecosystem is incomplete and inconsistent. There is also not one central place to find the documentation. Over the last year, we have started to work on development and deployment guides for Swift on Server in production. We want to make those and other related content more robust and easier to discover. Just as in all the other areas, we are relying on the whole community to help improve the content, to suggest missing content, and to voice concerns about the content and its discoverability.
Wrapping up, we also want to use this year to give your success stories with Swift on Server a bigger stage. There are many successful Swift on Server projects and deployments that most people have never heard of. We think that a platform like the SSWG can help to spread the word. So if you would like to share your story with our community, please reach out!
).
So yeah, we'll very soon catch up updating projects to use async/await.
let me know if you have trouble with it and I’m happy to share more pointers. I frequently use it and it works both on macOS as well as Linux.