Why Vapor?

Before sharing my general impressions, you may be asking yourself:

Jeff, why do we need a new server development framework? Don’t we already have a bunch?

To which I would say:

You’re quite right. We do have a bunch.

At MichiganLabs our primary server development platforms are C# + Dotnet Core and Python + Flask. My biggest complaint with C#, until the recent changes with C# 8.0, are its differing treatments of nullable reference and value types. As for Python, I’ve just not a big fan. To me, a strong, static-type system is necessary for writing safer code (or maybe I just enjoy the compiler yelling at me).

This brings me to Swift. Residing among a very small class of languages, it’s a strong, static system of type, especially of the nullable variety. My use of Swift didn’t actually begin on the server-side. Like many others, my first taste was with iOS projects. With Vapor, I can leverage that experience in a new domain. Better yet, my time spent learning Vapor may even pay dividends back to iOS development. It turns out the SQLite driver for Vapor’s ORM “Fluent” runs on iOS, providing an alternative to Core Data with the potential of sharing code directly with your server.

Getting Started

The easiest way to kick off a Vapor project is through the Vapor toolbox command line program. Installation instructions and how to generate your first project are clearly spelled out in docs. If you’ve used Vapor in the past, note that Xcode now has first-party support for the Swift Package Manager. As a result, you can directly open the Package.swift file generated by the Vapor toolbox. In other words, you no longer need to generate an Xcode project to develop in Xcode. A further advantage of this integration is that Xcode will automatically fetch and resolve your dependencies whenever you change the Package.swift file.

The template project comes with a couple of example models and routes to get you started. One tip I can offer is to break up the functionality in the generated configure.swift file into at least three files:

• configure.swift - Where you configure plugins / middleware / services
• routes.swift - Where you add all your routes to the application
• migrations.swift - Where you add your sequence of migrations

I’m fairly certain my preferences for how and where to put things will change over time; however, this small amount of compartmentalization has been working well so far. New projects are easy to set up, and begin working quickly. Vapor puts enough tools at your fingertips to dive in, but not so many that it becomes overwhelming. There is also a growing community of 1st and 2nd party frameworks to be found in the vapor and vapor-community GitHub organizations, as well as 3rd party frameworks.

Running Your Application

When it comes to running your server, you have a host of options. From your development machine, you can

• Develop, build and run all within Xcode

• Build and run from the command line using the Swift CLI

• Build and run using Docker
  

The option you choose largely depends on how your development environment is set up. If you are happy enough with Xcode, then keeping everything in the IDE is a reasonable option. If you are a container connoisseur, and value having your development environment closely mimic a deployed one, then Docker may be the option for you. Thankfully, the Vapor community maintains its own Docker image suitable for building your Vapor projects (vapor/swift:5.2)

The same goes for a deployed environment. A couple of options for running your code remotely are Docker, and using something like the Vapor buildpack on Heroku. Because Swift runs on Linux, the deployment story is not all that different than a language like Python or C#.

Boiling The Water

All in all, I’ve been happy with Vapor 4. Mostly I enjoy the Swift ecosystem (and the Vapor community is no exception). One drawback with Vapor is the sparse documentation for v4 and its related frameworks. I’m looking forward to getting that squared away as Vapor progresses out of the release candidate stage.

In the meantime, resources like the Vapor Discord server and the tests that can be found in the source code are doing the trick. The Discord server is especially responsive to questions, suggestions, and bug reports. With that, I leave you with several pros and cons to consider if Vapor is in the running for your next project.

Pros:

• Built on top of SwiftNIO2

• Everything is async by default

• Very low resource requirements

• Re-use language knowledge from iOS development

• Can potentially reuse code on a native iOS client

• Vapor’s FluentSQLite runs on iOS

• Discord community is great

• Developers are very responsive to questions and bug reports

• Framework tests contain a wealth of examples that can help you learn

Cons:

• Documentation is currently lacking

• Development on macOS requires 10.15+ (Catalina)

• Vapor and related frameworks are still progressing out of release candidacy into 4.0 official

• If you have allegiance to a different framework, Vapor probably doesn’t have the goods to make you want to switch