Server-Side Swift

"My goal for Swift has always been and still is total world domination. It’s a modest goal."

With that in mind we shouldn't be surprised, that there are three frameworks in Server-Side Swift that you can use to create a backend: Perfect, Kitura and Vapor.

I'll focus and compare the last two of those... Why? Because Vapor (according to Github stars) is the most popular one (it has recently outgrown Perfect), and while Kitura is the least popular one, IBM is standing behind it, making it a more natural choice for enterprise backends. I'll also try to answer the question of whether is a good idea to use Server-Side-Swift in the broader context of more popular frameworks.

Vapor vs Kitura

At this point, both Vapor and Kitura came close to feature parity. Let's make a general overview, without getting into details:

Installation

Both frameworks can be installed via homebrew:

Vapor

brew tap vapor/tap
brew install vapor/tap/vapor

Kitura

brew tap ibm-swift/kitura
brew install kitura

Creating a project

Both have a simple project template to kickstart development and are easy to use with Xcode:

kitura init
swift package generate-xcodeproj

vapor new ProjectName
vapor xcode -y

Package Management

Both frameworks use Swift Package Manager. Right now, Server-Side-Swift may be the single most important thing that will make SPM popular, as iOS developers are more accustomed to CocoaPods and Carthage.

Validation

Kitura gives you Kitura-Credentials, which makes it simple to write any authentication you want by yourself. It was built with OAuth2 in mind, so you can connect with any OAuth2 provider you want. It also gives some examples of this implementation with Kitura-CredentialsFacebook, Kitura-CredentialsGitHub and Kitura-CredentialsGoogle. As of now, there are third-party (non-IBM) implementations of Twitter and Discord as well.

For the same purposes, Vapor uses a framework that's simply called Auth, but to use it, you will need Fluent ORM as well. To have OAuth you will also need Vapor OAuth and Vapor OAuth Fluent libraries, so things are a little more complicated here. Finally, when it comes to the existing implementation of specific OAuth2 providers for Vapor, you are on your own. No easy-to-use examples.

Last but not least, both Kitura and Vapor support what has now become the standard: JSON Web Token, with IBM's library SwiftJWT and Vapor's JWTKit. Both libraries can be used not only with their counterparts, so you can choose which you want to use independently from the rest of your choices. You can even use them to read JWT on mobile applications!

Databases

Kitura has a Swift-Kuery which is only an abstraction layer over SQL databases, but if you need more, there's a full-featured Swift-Kuery-ORM build on top of that. Right now there are plugins that support PostgreSQL, SQLite and MySQL.

Vapor has a Database-Kit as an abstraction layer over SQL and it's own ORM called Fluent ORM. Right now there are plugins that support PostgreSQL, SQLite and MySQL, and MongoDB is in the works.

Speaking of NoSQL solutions: MongoDB provides it's own Swift driver while CouchDB is provided by IBM's Kitura-CouchDB, though both should work on Vapor and Kitura.

Templating systems

Both Kitura and Vapor have powerful templating systems:

Vapor uses Leaf, powered by TemplateKit engine. The syntax is Swift-inspired, making it a pleasure to work with. Simple as that.

Kitura uses Stencil for templates with Kitura-TemplateEngine and Kitura-StencilTemplateEngine plugin. Stencil's biggest perk is it's biggest downside as well: It's similar to Django and Mustache. Thanks to that, if you know them, or want to learn something that will be interchangeable between frameworks, Stencil is great. But if you love Swift and want to use it everywhere, bad luck: Stencil’s syntax is far from Swift.

While I found some implementations of other templating systems for both Kitura-TemplateEngine and Stencil, they turned out to have little to no popularity or were marked as No longer maintained. Maybe in the future, we will have more choice, but right now choosing the framework will restrict your templating choices.

CORS middleware

In Vapor, you get it out of the box. You just need to add it to the list of middlewares you want to use in Config/droplet.json. In contrast, with Kitura you will need to add a package called Kitura-CORS.

Docker support

Initiating a new project in Kitura will automatically create Dockerfiles needed for docker deployment. From there, it's simply a couple of commands to have your backend dockerized.

Vapor does not support Docker out of the box but there are tons of articles online on how to set it up, so I wouldn't consider it a big thing. And you can always use the preconfigured Nodes-Vapor/Dockerfiles to get a similar effect to Kitura.

OpenAPI Support

OpenAPI is supported only in Kitura, but it should come with the newest Vapor release.

Writing code

Vapor is actively promoting the use of Future/Promises in concurrent solutions and has its own implementation for it. Kitura is far more conservative, only using syntax that is built into the Swift language itself. This is in fact an example of the greatest difference between these two frameworks.

The approach to technology

Kitura is a child of a corporation and everything in it will remind you of that. A new feature needs to be thoroughly tested before it's production-ready and you can wait years for this "brand new coding approach" or "under the hood improvements" to come to Kitura. And everything's backwards-compatible. Obviously. Vapor stands in stark contrast to Kitura, trying to adapt everything that's cool as soon as possible, without the fear of breaking changes.

Popularity

Vapor is much more popular inside the Swift community, though we need to remember that IBM is standing behind Kitura's lightning-fast development, so both Vapor and Kitura are in a really good place when it comes to their future.

So as you see both are equally good choices. The real question is…

Should I use server side Swift at all?

Well, as with everything, this will depend on your use case.

Good reasons

• If you are an iOS developer that wants to learn backends. Use Kitura and you will use a stack that's more similar to the rest of the web development world, and it will allow you to translate your Kitura skills to other backend frameworks.
• If you are a web developer that wants to learn Swift. Use Vapor. It makes extensive use of Swift and ignores web development standards in favour of squeezing out 110% of what makes Swift great.

• If you want to prototype and create a proof of concept. Both are good.
• If you need a really simple backend in no time and you already know Swift. Both are good.

Bad reasons

• If you want to create a backend out of existing modules without reinventing the wheel. While all Swift backend frameworks are adding new plugins daily, their number is still far lower than in any other popular framework. You will end up writing everything from scratch.
• If you want to create and maintain a website for years or hire somebody to do so. Server-Side-Swift is an exotic stack. Right now there are exactly 0 job offers worldwide on the most popular job-hunting platforms for Kitura/Vapor developer, which means you won't find a developer to maintain your project for you. Or you will need to pay extra to an iOS developer willing to switch from mobile to backend.

Keep in mind

• I couldn't find anything about remote debugging, other than this really old documentation.
• While Swift reached ABI Stability and finally got Language Server Protocol, it's still early days for Swift outside of Apple’s ecosystem. CLion is right now the only reliable IDE for writing the Swift code on Linux (and there are none for Windows!). Only macOS and Ubuntu are officially supported, and for Server-Side-Swift to be popular it needs to be available on all popular OSes and all popular IDEs. The most disappointing thing is that it's been almost a year since Kitura Studio's beta release and it's still a macOS exclusive (also, it's based on Eclipse and Eclipse has not been getting any traction over the past years).
• There's no major player in the IT world to provide their services using Vapor, Kitura or Perfect. Somebody needs to prove that Server-Side-Swift is ready for the world to make it a popular choice. Nobody wants to be on the bleeding edge, so why should you?
• StackOverflow's tag Kitura has a total of 80 questions. Vapor is a little bit better, with nearly 500 questions. To put that into perspective, iOS has 607149 and asp.net 348840. What does it mean? If you encounter a problem, you're on your own!

Conclusions

I think that Server-Side-Swift is not production-ready yet for anything else but prototyping, but if Swift, Vapor and Kitura develop with the current velocity, it soon will be. We need to wait for some major player to build something recognisable with Server-Side-Swift so that the people outside of Apple’s ecosystem will jump on the bandwagon.

Photo by israel palacio on Unsplash