Swift on the Server?
In the early days of Swift one of my colleagues said that “writing in Swift is like riding a nice new bike down a freshly tarmacked road — until the road disappears and your bike explodes”. 💥 Swift has come a long way from that state in the last few years, with no more source kit crashes and large amounts project refactoring required every time a new version gets released. However, when it comes to running Swift on the server you could say that we are still in the bicycle exploding phase…
This article contains all the context and resources I wish I had when I started writing Swift on the server. I hope it helps you get started! (There’s a list of useful resources at the bottom 👇 if you just want to skip to that bit)
When Swift came out as an open-source language there was no doubt that people would start creating cross platform server-side frameworks for it. However a lot of people were doubtful whether Apple would work to help support this. Recently though they company set up an official work group on swift.org saying:
“Swift has amazing potential on the server, and to be an even better language for server-side development Swift needs great low-level APIs common among server frameworks. The Server APIs project will provide core capabilities in areas such as networking and security so Swift programs no longer need to frequently rely on platform-specific C libraries to provide this functionality. As a result, developers will be able to create frameworks and server applications using pure-Swift code, without the need to also have systems programming skills and knowledge of multiple platforms.”
This is a huge step forward for Swift on the server. Apple’s collective brings together some of the leaders in Swift back-ends, such as the creators behind the popular frameworks Kitura, Vapor and Perfect. This group hopefully will bring huge progress to server-side Swift. For one thing, if the C libraries we currently rely on are removed and replaced with all Swift ones, we should see a great increase in speed.
Why Swift on the Server?
The main people who are switching over to server-side Swift right now are iOS developers who want to create their own back-ends without switching to a different language.
The work I do in the concept team at Founders Factory is largely about prototyping new ideas. Often I need to rapidly create my own back-ends for some of our early stage iOS prototypes, and I first started to use Swift on the server because it had a much lower barrier to entry than learning a new language. I could also use the same Swift frameworks I’ve built over the years, (with a few tweaks to make them work on Linux), greatly reducing the learning curve.
One Size Fits All
Personally I’m not a huge fan of software that claims to be ‘write-once, deploy-to-all’ especially when it comes to mobile development. Apps written in this way are functional, but they often lack that native feel we all know and love.
What is appealing though is shared business logic. Imagine being able to share your models between iOS and your back-end: when you add a new property to a model on the server, your front-end app can already ingest it!
We have Swift on iOS and Linux but the big change will come when Swift can be used for Android development too. While some people have already hacked together versions which compile to Android, Facebook are currently working on creating a stable version, and I hope they will release a working version soon. The possibility of writing your business logic once and being able to run it on iOS, Android and Linux while still having a native UI layer is very exciting.
Working on Linux
If want to deploy your work its pretty likely you will deploy it to a Linux instance meaning you need to make sure your app runs correctly on it. One important thing to understand though is that a lot of the frameworks and API’s you’ve previously worked with in Swift may not run on Linux. This is because Apple and the open-source community are still porting Foundation to be supported on the Linux kernel.
The one that caught me out most when I started was
URLSession.shared(). I used this function all the time on iOS and Mac but unfortunately the global shared URL session is not yet supported on Linux, instead you have to create your own session like so:
let defaultSessionConfiguration = URLSessionConfiguration.default
let defaultSession = URLSession(configuration: defaultSessionConfiguration)
I would highly recommend running a local Docker instance and testing your builds on Linux as you are working. It really helps to avoid big refactors due to missing functionality. Perfect’s Mac app can set this all up for you automatically and works with Vapor as well! You can find out what is yet to be implemented in Foundation in the official status documents.
If, like me, you need a nice networking library that runs on Linux and Mac you can use the one I wrote here. Its a lightweight wrapper around
URLSession and handles some of the JSON encoding / decoding for you. It is still a work-in-progress, is missing some functionality and has very little documentation but it works on both platforms and I’m adding to it every week!
Contribute to factory.swift-tools development by creating an account on GitHub.github.com
Which Framework is Best?
There are three major server-side Swift frameworks: Kitura, Vapor and Perfect. They all have their advantages and disadvantages and it largely comes down to personal preference and context when choosing which one to use for your project.
Perfect in my opinion is great for getting started quickly, grasping the fundamentals of server side swift development and building light scrappy back-ends. I’ve also found that Perfect is by far the easiest to deploy to AWS especially with their Mac app. Of the three, they have the most extensive documentation about their framework and the common libraries that you can use with it, so its a great place to start if you’re new to Swift on the server.
Vapor has a lot of potential and their framework takes out a lot of the typing involved in back-end development. A lot of work goes into serialising and deserialising models to/from JSON, or from models to databases, and Vapor takes a lot of that work out for you. They have also just launched Vapor Cloud which allows you to deploy very easily and takes away a lot of the complexities around scaling. Once Vapor 3 is released, I will be switching to using Vapor as my framework of choice.
Kitura has the full force of IBM behind it and this really shows, especially when it comes to their tooling. They have an awesome Mac app for working with Swift and its package manager, and have also launched a Package catalog which is a great resource for finding reliable packages for development. This was the first framework I used as it was presented at WWDC a few years ago. While it was easy to deploy to IBM’s cloud platform, getting Kitura up and running on AWS is much more difficult.
If you want to get into the nitty gritty of performance, Ryan Collins wrote a great post on the comparison between server-side Swift frameworks which is a useful read.
Hopefully you’ve been convinced to try and build your first Swift back-end! The resources below should help you get started. I highly recommend Vapor University: it is an extensive library of tutorials and documentation which will guide you through from start to finish.
Best of luck!
Learn to build Swift on the Server — Vapor University
Apple’s Swift API project — Workgroup & Thinking
For finding useful Swift packages — IBM’s Swift Catalog
Seeing what is compatible with Linux — Apple’s Foundation status page
To test your builds locally on Linux — Perfects Mac Assistant
Linux and Mac compatible network wrapper — MagicRequestController