Development

Putting a Kettle On: Server-Side Swift with Vapor

March 23, 2020
Putting a Kettle On: Server-Side Swift with Vapor

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

Jeff Kloosterman
Jeff Kloosterman
Head of Product Development

Looking for more like this?

Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.

What the smartest executive leaders are doing right now
Business

What the smartest executive leaders are doing right now

July 25, 2024

We are consistently seeing three things right now in terms of how executives are tackling the technological challenges they are facing.

Read more
Lessons Learned from our Associate Developer
Team

Lessons Learned from our Associate Developer

September 13, 2023

One of our Associate Software Developers, Rohit, reflects on his time at MichiganLabs working on a short-term project, what he learned about real-world development, and the software consultancy business model.

Read more
A Study of Human-Centered Design Off Screen - Burning Man Festival
Design

A Study of Human-Centered Design Off Screen - Burning Man Festival

February 13, 2023

Kourtney examines the Burning Man Festival and its fascinating history of human-centered design

Read more
View more articles