Today we are open-sourcing backend of Swift Talk. We recorded a number of episodes of building it, all of which are gathered in the Server-Side Swift collection. Full source code is on github.
Before we started Swift Talk we spent a lot of time figuring out the format. We registered a lot of pilots and discarded them all before we decided on the current style of conversation. Because we were so busy finding out the format and content, we decided to outsource our backend development.
We worked with an external contractor who built the site in Rails. We didn't feel that Swift was ready yet, and had some experience with Rails ourselves. Because of our lack of experience, and because Swift and Ruby are so different, making changes was extremely time consuming.
By refactoring in Swift, we strongly rely on the strong, static type system. For example, this allows us to change a method signature, and the compiler guides us through all call locations (in addition to any tests that are in place). In Ruby / Rails you cannot rely on a static system, but instead rely solely on a comprehensive test package to guide refactoring.
Similarly, Ruby on Rails is dependent on meta-programming, making it possible to achieve much with very little code. But if you are not familiar with the frame, it means it can be quite difficult to track through your application and understand what is happening.
Finally, our Ruby codebase had many dependencies. Even for such a simple project, it had 75 Ruby dependencies (some were transitive, but most were direct addictions). Over time, these had to be updated, and we needed to make sure all the addictions and code stayed together as expected.
After completing our latest book, App Architecture, we decided it was time to write about the backend. Although there is no direct business value, we wanted it mostly because it is a fun and interesting project. We wanted to prove to us that Swift was possible as a backend language, that we could rely on the refactoring type system, and that we could do with minimal dependence.
In recent months, we have shown ourselves that all these things were true.
For example, to clean up the code so that others can read it, we took out things in frame conditions, made some big turns, and refactored a bunch more. The compiler and the type of system was a great help there.
We have only six direct dependencies: the Web server library (NIO), a postgres client, a markdown library, an XML parsing library, an encryption library, and the SourceKitten (for source code extraction). Most likely, we are not using a web frame, but we decided to structure the code in our own way.
So far, we love working with this code. With so little addiction it means we almost own all our code and can design and expand it in a way that works for us. Instead of being stuck with a Rails backend that was difficult to change (for us), we can quickly add features (such as the new team member).
For us, the biggest down side is that Swift on Linux is not yet battle-tested yet. We ran into a few errors (especially about URLSession / URLRequest behavior), but they were easily fixed or worked around.
We are not the first to build a project like this in Swift. The fact that Point-Free was written in Swift has been an inspiration to us. For example, it is no coincidence that Dockerfile is so similar to theirs.
We are planning to add more features to Swift Talk, and we hope that by opening our source database, other people will be inspired to write their backend in Swift as well. We have some more episodes where we explain how to work in our backend, so if you are interested, subscribe today.