May 19, 2016

Server-side Swift notes

This is the result of a recent look into server-side Swift for my own personal use. This area is changing everyday, and with less than a month until WWDC, expect most of this to become incorrect in the future.

It all started with me researching the Amazon Alexa Skills SDK: apparently those are just calls to a previously defined Web Service with a predefined list of commands. And since I live outside the US testing Alexa is tricky, so I decided to try my idea with something similar: Slack’s slash commands.

I’ve heard that Swift on the server isn’t for serious projects so this was a perfect fit. With that in mind I followed Ben Snider’s tutorial (thank you) and quickly discovered that this wasn’t exactly the Swift I was used to.

The following is a list of caveats, problems or notes produced during this short project.

Managing Swift versions #

The .swift-version file contains the Swift toolchain version your package needs. I tried changing it to a couple of different values with no success, either it would fail to download or fail to compile the dependencies. swiftenv uses those version names to download the binary and it seems things are unstable regarding URLs.

Swift Package Manager #

Notice I said package instead of application. That’s because it is a package.

import PackageDescription

let package = Package(
  name: "TheSlackCommand",
  dependencies: [
    .Package(url: "https://github.com/kylef/Curassow.git", majorVersion: 0, minor: 4)
  ]
)

This isn’t something exclusive to server-side Swift and I expect Apple to add SPM to Xcode eventually. If the community starts supporting it and adding these Package.swift files this might be a strong alternative to CocoaPods.

I had problems with dependencies. Curassow depends on a couple of other packages and I choose a Swift version that wasn’t compatible with some. Again, it’s all so early stage.

#if os(Linux) #

I was used to an Apple controlled environment, OS X and iOS, but when deployed to Heroku Swift runs on Ubuntu. That meant some BSD functions didn’t work and Foundation wasn’t quite as polished.
I’m positively surprised Foundation is present at all and it’s great to see how active the project is.

The middle layer #

Ben suggests Curassow as an HTTP server and I was glad to find it’s open source and designed to be fast and simple. So simple it went from great for starters to missing features very quickly, i.e. JSON parsing, sessions, multipart requests, etc.
Perfect.org looks more mature but apparently it can’t be added by just declaring it as a dependency. In the future I intend to try it but for now what I have works.

Deploying #

Heroku was very easy to deploy, but at the first sign of trouble I was clueless where the logs where, error messages, anything. That and the mandatory sleep time pushed me to another platform. Since last week Heroku announced changes to it’s free dyno plan in terms of hours so I will try it again next time.

IBM Bluemix #

The deploy was also super easy and for what I need is very similar to Heroku. Anyway I found it’s dashboard easier to use and was able to build what I needed using it.

In summary I wouldn’t use Swift for anything serious on the server-side. There’s almost no information online and the tools aren’t as easy as you might be used to if you’re coming from iOS. On a positive note it’s great to see there’s multiple choices for cloud services and libraries already. For example Zewo looks great and has Linux support right in the title. Swift has made my code better and it makes me happy to see such open community built around it.

Kudos