In Part 3 we started working with a `Park` model and defined two endpoints that returned information about parks. We used an in-memory array to hold `Park` instances. In this tutorial we'll set up a PostgreSQL database . . .
In Part 2 we explored the basic structure of a Vapor app. Next we'll look at how to declare simple routes with dynamic path components and query parameters. Our API will model information about U.S. national parks, so we'll start by declaring a simple `Park` model. For now, we'll keep an array of parks in memory and define two routes.
In this tutorial, we'll see how we can use protocols to make custom view subclasses more generic. The benefit is that they'll be easier to test and reuse, and our code will be easier to read and maintain.
In Part 1 we saw how to install Vapor and create an Xcode project using the default `api` template. That project comes with a lot of code demonstrating the basics of building an API in Vapor. It uses SQLite as the database and a `Todo` model and controller as an example. Our app will eventually use PostgreSQL . . .
Vapor is a web framework for Swift. It runs on macOS, iOS, and Linux, and can be used to build websites, web applications, and APIs. Frameworks like Vapor make it possible to build entire products in Swift, including a backend, web app, marketing site, and Apple device app (iOS, macOS, tvOS, watchOS).