SSWG Annual Update 2020

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, 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:

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

gRPC Swift provides official gRPC support for clients & servers written in Swift.

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

A library containing Swift types that encode to- and decode from OpenAPI Documents and their components.

MongoSwift

The official MongoDB driver for Swift applications on macOS and Linux.

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

This Swift package provides support for automatically printing crash backtraces of Swift programs.

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

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:

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!

54 Likes

Thank you for this great write up! It’s been a pleasure being part of the community so far and I think the future directions will allow it to grow further! Having SSWG “signed” projects through the incubation process helps tremendously in choosing high-quality tools/libraries and is something I miss in other ecosystems whenever I’m not using Swift (which these days is not very often :slight_smile:).

This sounds like a great idea. Giving success stories a shout-out will definitely help in convincing project leads to consider Server-Side Swift as a viable option.

@0xTim Your post on our tracing experience so far is a great example of this and maybe we can also write about the project in general as well.

11 Likes

Oh yes I have several other thing planned as well as the things already published like Replicating DynamoDB to Elasticsearch with a Swift Lambda

9 Likes

Great work! :tada:

3 Likes

Thanks for the nice write up! Big +1 to the three focus areas, excellent choices!

4 Likes

Very great work last year and excited for the changes this year! The one question I have is about the transition from EventLoopFuture based concurrency to async/await. I see that SwiftNIO and Vapor packages have some experimental support for async/await but some packages like the Swift AsyncHttpClient do not. What is the best way to develop with async/await in this transition period? Should I wait for Swift 5.5 stabilize further?

These updates are great, especially as talking points to share with others!

Two points of feedback:

  1. Shouldn't the title say 2021, and not 2020? :smirk:
  2. Per Sept 2nd, 2020 - #3 by kmahar - where will feedback for packages on their incubation status be posted?

In hindsight I'm realizing that update is more of a review of 2020, rather than a report on 2021 :man_facepalming:

5.5 has not been released yet :wink: So yeah, we'll very soon catch up updating projects to use async/await.

We'll also work on a plan and guidance for library authors in the server ecosystem for doing so -- as Johannes wrote, that's one of the topics we'll be focusing on.

2 Likes

Great work everybody!

On this note, I wish the official Swift twitter account served for more than posting links to the official blog. I think it has a huge potential to share nice things from the community, like what you mention.

4 Likes

@Alejandro_Martinez sort of like a community showcase sort of thing?

1 Like

If you look at the Rust twitter account you can compare how much active it is and how it shares and RT things from the community, or even questions newcomers have. It feels very nice and useful.
But I’m not sure who manages the Swift one, if it’s part of swift.org or Apple.

4 Likes

Great to see all that has been done, but I feel left out as I don't code for the server. Has there been any thought of creating a Client Working Group also, to provide similar foundational open source Swift packages and help to those writing Swift for clients, ie all Apple platforms like iOS, Windows, Android, Fuchsia, etc.?

I'd imagine you'd have a much larger userbase and group of devs willing to contribute. Of course, there is crossover for client and server, as some libraries like swift-crypto could be used for both and tooling is a matter for everyone, but some needs are different for each.

It seems SSWG has been a successful approach to spur Swift on the server, any consideration to doing the same for clients?

1 Like
Terms of Service

Privacy Policy

Cookie Policy