Getting Started with Vapor

Episode Links

• Vapor
• iTerm2
• Episode 319 - Setting up the Terminal - This screencast talks about my iTerm2 setup
• Episode 324 - Setting Up a Ruby Development Environment
• Swift NIO - Apple's open source project for high performance, non-blocking I/O, which provides the underpinnings for Vapor's architecture.

Installing Vapor

To work with vapor, we'll need to download the vapor command line tools. We'll do this with Homebrew:

$ brew install vapor

Once installed, you can create a new app like this:

$ vapor new hello_vapor

This will use their --api template by default. If you want to see an example website project, use the --web flag like this:

$ vapor new hello_vapor --web

Building the Project

The first time build will be extremely slow, but be patient. It has to download all of the dependencies and compile them all. Once the first build has completed, subsequent builds will be much faster.

$ vapor build

Now go make yourself a cup of coffee. Seriously.

Running the Project

To run the project and see it in action, type vapor run:

$ vapor run
Running hello_vapor ...
Running default command: .build/debug/Run serve
Server starting on http://localhost:8080

At this point, the server is running and the terminal will block here, waiting to serve requests.

You can open a browser and browse to http://localhost:8080 and see your server in action. By default, the /hello route will respond with a message.

To stop the server, hit ⌃C in your Terminal.

Any time you make changes to your swift code, you will have to stop the server, re-build, and re-run it.

Working in Xcode

Out of the box, Vapor leans on Swift Package Manager, which works without Xcode. You could, for instance, write a Vapor app entirely on Linux using a text editor and the command line tools.

Using Xcode does, however, provide extremly helpful code completion and build errors that will guide you into writing the correct Vapor code.

To create an Xcode project:

$ vapor xcode

This generates an Xcode project, and can be regenerated at any time, so it's important to think of the Xcode project file as ephemeral. You may even choose to not check this into source control.

That's it for now, next time we'll take a look at routing.