Server-side Swift with Vapor
Want to write your backend in Swift? In this series, we'll learn how using Vapor 3. We'll start by learning the fundamentals of a Vapor application, then build a couple practical examples of web apps and APIs. We'll learn how to save data to databases like Postgres, and how to deploy Vapor applications to cloud platforms like Heroku.
Length: about 3 hours.
In this episode we'll learn how to install the vapor tools, how to create new projects, and look at how projects are structured.
Vapor uses a router to determine how to process incoming requests. In this episode, we will see how to define routes and how to return simple responses. We will see how to return custom JSON responses, how to accept JSON posts, and how to deal with requests with dynamic parameters.
Leaf is Vapor's component for rendering dynamic templates. Rather than writing HTML strings by hand in our router, we can write leaf templates that allow us to mix HTML with code. Since Leaf is a separate package, we will show how to integrate this into your project from scratch, to get an overview of how dependencies are assembled in a Vapor project.
When working with web pages, you will almost certainly want to share a considerable amount of HTML. By nesting templates inside of master templates, we can share common HTML structure, layout, and share styles and scripts. We will see how to define sections that can be customized inside of your templates, as well as how to extract common components into partials that you can embed inside of other templates.
Let's take what we have learned and build a simple web app. We'll leverage NSLinguisticTagger on the server and built a small UI that extracts names from provided text. We'll lean on everything we have used so far in this series: routes, templates, master templates, context data, and a little CSS to make the UI look nice.
Most server applications will need to store some data in a database. For Vapor applications, this is done with Fluent, a Swift Object-Relational-Mapper for persisting objects to a database. Fluent supports SQLite, Postgres, and Mysql. In this episode we will learn how to set up Fluent with a SQLite database for development. We'll create our first model object, and discuss how Fluent supports migrations for evolving the database schema over time.
Now that we have Fluent set up, let’s see how we can use it to add, update, and delete records to the database. We’ll get a taste for how futures work in Vapor, and we will also see some of the builtin features that Vapor has to make loading records from your routes really simple.
In this episode we take a deeper look at one of the fundamental building blocks that support Vapor's asynchronous programming model: Futures. Understanding Futures is really important to understand when writing Vapor applications.
In this episode we set up a new Vapor application to use Postgresql as the database. We'll see how to configure FluentPostgreSQL, how to create and set up a connection to the database, and look at the defaults for PostgresSQLModel. We'll also discuss the pros and cons of using UUID primary keys over auto-incrementing integers.
In this episode we look at customizing the table and columns that Fluent creates for us. In addition to customizing our column data types, we'll also have to lean on an extension of Postgres to generate UUID values for us. We'll see how to customize some of the column constraints to suit our needs, and then create a development route to test it all out.
If you want to track when records are created and modified, you can add some fields to your model and Fluent will automatically manage them for you. You just have to take care to define your TimestampKey properties carefully so they match what Fluent expects.
In the last 2 episodes we added some behavior to add automatically managed timestamp fields and some fairly complex logic to set up UUID primary keys the way we want. Now if we want to share those, or make them the default for our models, we currently have to copy & paste. In this episode we will refactor this logic into reusable protocols so that our work can be applied on any model we wish easily.