Web server framework choice/preference

I've been experimenting with the popular HTTP server frameworks (Vapor, Kitura & Perfect) to use in a framework I'm working on. While doing research, I noticed that most comparisons, discussions are a bit outdated and the frameworks have changed a lot since then.
I noticed that Vapor is the only one that uses SwiftNIO while being mature, the rest have NIO implementations/branches but still in beta/experiment phases.

Anyone who used or planning to use one in production, what are your preferences/observations? In terms of development, performance, etc. Any insights/discussions are appreciated! :grinning:


CC @tanner0101 / @Logan_Wright / @Rudrani / @Pushkar_N_Kulkarni / @kjessup / @tachyonics

1 Like

I use Vapor on a daily basis and am very happy with it. Here are a few reasons I use it versus other options that exist:

  • Kitura (and Zewo, if you happen to be old enough to remember it) is no longer supported. IBM recently announced that they will no longer be maintaining the Kitura framework, so that's probably not a great option if you want to do server-side Swift for any length of time.

  • Swiftiness. When I started doing SSS around 4 years ago ( has it really been that long? :sweat_smile:), I did try out the various options. In the end, I felt that Vapor's framework and core packages felt the most native to Swift. Others, such as Perfect, felt more like writing a Node.js server, mutating existing Response objects versus just returning the data I want, for example.

  • Community. I hear time and time again from newcomers that Vapor has the most helpful and friendly online community ever. I can't personally vouch for this because I'm not involved in a lot of online communities, but I can confirm there are some really great people on our Discord server.

  • The development of the Vapor framework continues at what feels a breakneck pace at times. This can have the disadvantage of most of your project breaking between major versions, but I personally love it and can count on Vapor taking advantage of all of Swift's latest features (in cases it would make sense, of course, we don't really need function builders, but property wrappers allowed us to create a pretty sweet ORM).

  • Maturity. Vapor is one of the most mature frameworks in the SSS world. While it doesn't get even close to the level other frameworks such as Ruby on Rails and Node.js have reached, Vapor is more mature and has greater package support than, say, Smoke (by Amazon). This point will slowly become obsolete over time as the Server Side Working Group continues to roll out framework agnostic packages and other frameworks age, but it's good to keep in mind for now.


Thanks a lot @calebkleveter! This is exactly the kind of comparison I was looking for!

Hi @_saleh. My team within Prime Video builds and maintains the Smoke Framework. We use it in production in a very non-trivial way so we are committed to it and supporting it. I've been happy with its performance both in terms of the latency and TPS that we have been able to obtain. It is primarily designed to exist within the AWS ecosystem so it itself is lightweight and relies on other services provided by AWS (APIGateway for authentication and call metrics, Cloudwatch for instance metrics and logging etc). To this end we also maintain SmokeAWS to provide access to these services.

The Smoke Framework is primarily designed around the use case of handling the operations of an API description from something like a Swagger spec. Vapor handles a broader set of use cases including web page rendering so I think Vapor is now the primary option if that is what you are interested in. We have just released version 2 of both SmokeFramework and SmokeAWS which uses SwiftNIO 2 (which the recently-released Vapor 4 does as well).


@tachyonics this is amazing! I only heard about Smoke before but didn't know much about it. Now that SwiftNIO has became the standard base for networking frameworks, it's definitely a choice factor in any case. In my case it's mostly APIs. I'm definitely going to try it and deploy demos of my scenarios. I'm considering supporting multiple frameworks depending on results. It feels really good knowing there are such frameworks with commitment to support & improvement. Thanks a lot!