Putting a Kettle On: Server-Side Swift with VaporMarch 23, 2020
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.
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.
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
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
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
MichiganLabs named to Inc 5000 Fastest Growing Companies in the U.S.August 11, 2022
Michigan Software Labs has earned recognition in Inc. magazine’s influential Inc. 5000 list. The list represents a unique look at the most successful companies within the American economy’s most dynamic segment—its independent small businesses.Read more
How we approach UX @ MichiganLabsJuly 29, 2019
At Michigan Software Labs, we focus on building superior user experiences (UX) for our clients and their customers.Read more