"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.
At this point, both Vapor and Kitura came close to feature parity. Let's make a general overview, without getting into details:
Both frameworks can be installed via homebrew:
brew tap vapor/tap brew install vapor/tap/vapor
brew tap ibm-swift/kitura brew install kitura
Both have a simple project template to kickstart development and are easy to use with Xcode:Kitura
kitura init swift package generate-xcodeproj
vapor new ProjectName vapor xcode -y
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.
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!
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.
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.
Both Kitura and Vapor have powerful templating systems:
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.
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.
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 is supported only in Kitura, but it should come with the newest Vapor release.
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.
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…
Well, as with everything, this will depend on your use case.
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.