The second day of the Swift Server-Side conference was as packed with great talk as the first day. You can read my previous post on workshop and day 1.
Building the next version of the Smoke Framework (Simon Pilkington)
Simon Pilkinson introduced his rework on the Smoke framework, developed as a video ingestion platform for Amazon Prime Video.
This is a Swift framework, that is used to accelerate the development of API in Swift. The framework starts with a Swagger API description and generates all the needed code to provide API matching the specifications.
The version 2 of the framework is on the way and focuses on improving the workflow, as the performance in production are already great.
How we Vapor-ised our Mac app (Matias Piipari)
As expected, many developers in the Swift Server-Side community are coming from either iOS or Mac development. Swift server is for those developers a way to reuse both code and skills to produce server-enabled applications.
Matias talk is about such a story, moving from a pure desktop app to write Research paper on Mac, M to a collaboration tools, usable both on Mac and on the web.
The transition has been successful, but this is only a start, as several shortcuts has been taken to be able to release a version 1. For example, for now the server application is only running on Mac servers, as some pieces of code requires UIKit to be able to build. The next step is to make the code more modular to fully remove the UIKit dependencies on the server components, to be able to run them on Linux.
Supercharging your Web APIs with gRPC (Daniel Alm)
Daniel Alm, presented his work on gRPC Swift. He worked with George Barnett to provide a great support library for building and consuming gRPC services.
gRPC is based on protobuf and allows describing API in protobuf, using protobuf as a format for parameters and responses. It is slowly becoming a de facto standard format for API that are efficient to decode and more stable than JSON ones. You can for example rename a parameter in your code without breaking your clients.
As noted by Ian Partridge:
gRPC Swift is a lot further along than you might think. There is protoc support for generating Swift service stubs plus production ready client and server libraries, and it all runs on SwiftNIO’s implementation of HTTP/2!
And indeed, this is a big piece in the Swift server ecosystem.
If you want to try it, make sure to use the new nio branch, which is based on SwiftNIO.
Building high-tech robots with Swift – a story from the front lines (Gerwin de Haan & Mathieu Barnachon)
Another great talk describing a very practical and impressive use case for Swift in general and Swift server-side more specifically.
Styleshoots is building tools & robots to improve the workflow of studios shooting images and small videos for e-commerce sites.
They started with small robots to take pictures with a high-end DSLR camera, controlled by an iPad.
When they needed to ramp up to larger systems to be able to perform model shots and take small video for social networks as well, they needed server components (for example for remote maintenance and coordination / parameters exchange between multiple robots).
Moving to Swift Server side was a natural fit for them and despite some attempts to try other server side tools like NodeJS, they went back to Swift Server-side. It is a better fit with their team, allowing to reuse both code and skills.
You should check out their web site, as the tools are impressive.
Testing SwiftNIO Systems (Johannes Weiss)
This SwiftNIO test talk was one of my favorites. I am a big fan of testing tools (like Quickcheck) and technics. Johannes Weiss did a great job explaining how hard it is to test networking protocol stacks and how SwiftNIO modularity makes this task much easier. With a pipeline design, you can test one or two ChannelHandlers at a time.
The talk was packed with practical advice. For example, Johannes explained how to leverage SwiftNIO tools to help with testing, like EmbeddedChannel and NIOHTTP1TestServer.
I really recommend watching it, when it is released in video.
Maintaining a Library in a Swiftly Moving Ecosystem (Kaitlin Mahar)
Kaitlin Mahar put together a very engaging talk. She described both the process of proposing her Swift Mongo DB library through to Swift Server Work Group incubation process. You can read her proposal here: Officially supported MongoDB Driver.
But she also did more and gave many pieces of advice to help library maintainers improve their version management and API evolution. For example, in no particular order:
– Use semantic versioning
– Use @available attribute to let your users know about API changes and deprecation
– Prepare release notes and explains the reasons beyond your changes
– Prepare code migration guide in case of big changes in the API. Don’t let your users figure out by themselves.
– Set up your CI/CD to run test under all the supported OS and Swift versions.
– …
Fluently NoSQL: Creating FluentDynamoDB (Joe Smith)
Joe is maintainer of Fluent-DynamoDB library and is contributing to AWS-SDK-Swift. He explained how he got to write those tools to help improve the alerting platform at Slack.
Full stack Swift development: how and why (Ivan Andriollo)
The final talk by Ivan Andriollo was both a great conclusion for the conference and a great talk in itself.
I must confess that I found this talk unexpectedly good. It was a talk by a consultant, sharing his view on agile programming and why it makes sense to kick-start your project by prototyping for production using Swift Server side and iOS clients. This is a talk that can be easily boring or full of commonplaces.
But Ivan’s talk was both clear, exciting and presenting the ideas in a very convincing way. This is an approach I agree with, as build both Swift servers and clients is an approach we have been starting to deploy at ProcessOne.
To summarize in a few words, if you want to be efficient and produce a prototype of a mobile service, that can go to production, you can use a team of Swift iOS and Swift server developers to iterate fast toward the result. This is indeed the most efficient approach, limiting coordination cost between separate team. You can always add an Android client in a second stage, using the same API server (for example using gRPC).
This is a great conclusion for the conference, as this approach is the very essence and the most obvious raison-d’être of the Swift Server-Side ecosystem.
Conclusion
Swift Server-side conference 2019 has been my favorite conference this year. The talks were very deep and interesting, the venue was beautiful, and the food has been great. But, most of all, the gathering of such a good number of passionate people, working together to make Swift on the server a reality, has been an exhilarating experience. You all know that I am a creator, loving to build new stuff. After Swift Server-Side conference, I went back home with new friends and the confidence that, led by such a group of people, Swift Server-Side is going to progress steadily in the coming months.
