Hello, Server Swift

Since Apple officially released an open source version of Swift for Linux, server-side Swift has finally ushered in an exciting prospect. My curiosity can no longer be restrained, and it's time to try server-side Swift!

I have no backend programming experience except for a few Baas, but fortunately the open source community has already provided a ready-made framework. I tried the Vapor framework recommended by Tanner Nelson. It is very simple to use and very suitable for my current task. Heroku will also be used in this document. The reason I decided to use Heroku is that our backend team uses it and it is very friendly to the frontend.

At the time of writing this, I have submitted a pull request to fix a few minor issues with the framework running on Heroku. If the code has not yet been merged, please set your package manager to download it from here.

Install

To follow this tutorial, first, you need a Heroku account and install the Swift Development Snapshot. At the time of writing this, the Swift Package Manager is not yet included in its official version. Therefore, in order to use this tool, you must download the development version of the snapshot.

start

Our goal is to create a simple Swift server and run it on Heroku. This does not need to be done in a Linux environment, just like you are using a local server. You just need to create a local Xcode project, set up the project, and then run it in the Swift Package Manager. The whole process is divided into 4 steps:

Copy main.swift to the Sources directory in the root directory

Create a Package.swift file

Add the .build directory to the import paths

To use the auto-completion and syntax highlighting features, you need to submit the build directory of the Swift Package Manager to the import paths. Note that the debug directory is set in the Debug item of the import paths, and the release directory is entered in the Release item.

Run Xcode with toolchain

If you use Xcode 7.3, you can use the Xcode > Toolchains menu to open an Xcode instance to open the Swift snapshot. Since we can't compile in Xcode, we can only compile from the command line.

Writing the Server

I was delighted to find that the amount of code I had to write to perform a proof of concept was actually quite small. I had the server up and running in less than 10 lines of code.

To start the server, just enter a command in the terminal:

Ok, let's open the browser. My browser has the json plugin installed, yours may look different.

Migrate to the cloud

The server ran smoothly locally, but it would be even better if it was put in the cloud. I couldn't wait to run the App on the cloud. This was a new challenge for me, but fortunately, I got the careful guidance of Vincent Toms.

The Heroku installation was a very pleasant experience. Within a few minutes I had created a Heroku App and was ready to upload my project.

Something went wrong

This was just one of many errors I encountered today. I had expected that things would not be smooth sailing, so I checked the Vapor documentation and finally found that the problem was with the so-called buildpacks. Heorku provides some standard buildpacks, but there is no buildpack for Swift at all. I turned to the open source community for help and happened to see Kyle Fuller's buildpack. Integrating it was much simpler.

After launching with this buildpack, the App is successfully loaded and the next step is to access its URL.

Wrong again

Things can't be that smooth, right? After some googling and looking through some examples, I found that I was still missing a Procfile. Take a look at the contents of this file and you will understand what this file is used for.

The buildpack created the executable, but Heroku doesn't know about it. With the Procfile, we tell Heroku to run the SwiftServerIO executable. Upload this Procfile.

Still error

Heroku's compilation of branch 2 seemed to take an inordinately long time. I reopened the browser and found that the error message was still displayed.

I thought maybe Heroku hadn't started up yet (it wasn't), so I waited a little longer and finally realized something was wrong. The executable was built, the process file was ready, so something else must have gone wrong. More googling, until I finally realized I needed to scale up the app. This was done with a simple command in Heroku's toolbelt.

heroku ps:scale web=1

Heroku has only one dyno in the free case (Heroku billing unit, 10~50 requests/second). But for our simple server, this is enough. Therefore, after we set scale web to 1 dyno, check it with the browser again.

Success!

Success! The server is started and the almighty hello world appears! After all the cheering, let's actually ask hello!

Responding to a request

Add a small piece of code to the main.swfit file to allow the server to greet people differently. Let's be a little lazy and add a new route to allow the server to output different greetings based on the input.

Everything is working fine, but I am still prepared for things to go wrong. I commit the changes and push the code to Heroku.

Say Hello!

After about an hour of compilation, access the URL in the browser and the server returns a greeting. You can view the effect here.

What's next?

It can be said that the current status of server-side Swift is inseparable from the strong support of the community. For me, being able to get JSON from the cloud is an exciting start, and I can't wait to see what will happen next.

Of course, before that, I have to continue writing an iOS app with my colleagues at Intrepid Pursuits. If you want to keep up with my latest updates, please visit my Github or Twitter.

Server Swift

P.S.

Download the source code here.

In the Journal folder is a step-by-step guide.