Swift is an open-source programming language that was started by Apple and is now supported by a rapidly growing community. The Swift Evolution program will help steer the language to become not only more stable, but also modern and capable. This also includes the goal of making Swift a truly cross-platform language, a vast departure for Apple.
Many areas of software are exploring Swift, including VR, AI, and web. A big area that has been gaining support is using swift as a server-side solution. There are a number of possible advantages to using Swift this way, but some of the greatest reasons, in my opinion, are:
- Code reusability
- Focus for most code can be on a single, modern language
- Fewer languages/technologies needed for full-stack
- Client side and server side developers can more easily be cross-functional
Recently, Swift.org made the announcement of the Server APIs Project. As of right now, most of Swift’s networking capabilities are actually using C libraries. The project unites most of the large Swift Server-side project owners (IBM, Perfect, etc) to push forward native Swift capabilities.
A huge player in the server-side effort is IBM with their product, Kitura. IBM made a partnership to drive business users towards Apple by supporting a number of Apple technologies. Swift has become a huge player in this partnership for IBM and they’ve quickly latched on to the Swift journey (e.g. they created the Swift Sandbox, their own custom Swift Package Manager, and all of their mobile apps are written in Swift). A furthering of this partnership has been in developing Kitura, and server-side Swift framework. Though not the only solution out there (see Perfect, Vapor, and others), it comes with a slew of features that make it stand out. Specifically, IBM has surrounded it with many of it’s other services including BlueMix, Cloud Tools, and even Watson integration. And to measure the support/interest Kitura is generating, IBM had a special session at WWDC 2016 specifically on server-side Swift and, after it’s latest release, has been trending pretty rapidly on Github.
Resources to Get Started
Tech Details
Installation
The easiest way to get going is to clone IBM’s sample application.
Tutorial
Using in Xcode
If you’re a Mac/Xcode user, there’s a huge advantage in using Xcode to not only develop your Kitura server, but also debug and analyze it. So how do you convert your Kitura project to an Xcode project? Swift is able to self-generate an Xcode project with the following run in terminal:
swift package generate-xcodeproj
When you open the new project in Xcode, just change the scheme to the executable. Now you can run the sever. Trying placing breakpoints to explore debugging.
Package Manager
IBM has it’s own Package Manager to enhance the Swift package Manager. Add dependencies in the following format in the Package.swift file:
.Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 0, minor: 30)
To find more IBM featured swift packages, check out their catalog.
Routing
The low-level way to get started is to know how routes work. The router is a built-in Kitura class that handles requests to your server, which also includes sending out responses. Let’s breakdown the anatomy of a router handler that you would find in the Kitura-Sample project:
router.<#request type#>("/<#route title#>")
{request, response, next in
response.headers["Content-Type"] = "text/plain; charset=utf-8"
<#handle code here#>
try response.send("<#response#>").end()
}
The router class can handle your standard types of requests (e.g. GET, POST, PUT, etc.). The route title portion specifies the title that will point the router to this specific handler (e.g. example.com/hellowworldhandler). We get take in the request as well as a pre-formed response. We see that we can customize our response properties before we send it out. Now, in the handler block, this is where we can place the Swift code that we want to use to handle this request. There are essentially no rules here, you can access Swift classes, structs, frameworks, and even Foundation. Hence why Swift server-side is a desired framework because you can produce a Framework that can be common between your server and your app, reducing and reusing code. The only thing we need to do is at the end, where we finally send back our response to complete handling the request. Here’s a quick sample:
router.get("/helloworld")
{request, response, next in
response.headers["Content-Type"] = "text/plain; charset=utf-8"
let hwString = "Hello World"
try response.send(hwString).end()
}
Simple enough!
Request types (including all)
A cool route type is “all”. A route for “all” handles every request, even if there’s a more specific route. This is good to catch session, authentications, and also handling the parsing of requests.
ParsedBody
Kitura has a built-in request body parser. The types that we can expect are :
- JSON
- URL-encoded form
- text
- raw data
- multi-part