When Apple announced that Swift would be open-sourced and available for Linux, developers immediately began writing server software and frameworks in Swift with Vapor, Kitura and Perfect emerging as the top three. With very little provided by the standard library, each framework has come up with different ways of implementing the foundations they need. This has led to incompatible stacks, duplication of work, and could lead to fragmentation of the Swift server-side ecosystem.
With these concerns in mind, Apple announced the Server APIs Work Group a few weeks ago. The working group will be tasked with creating the foundation for server-side libraries and frameworks that will be cross-platform and will provide true Swift interfaces to the all the pieces they need. No longer will Swift developers have to wrap C libraries to get server essentials like SSL/TLS encryption or parsing HTTP. The end goal is to allow Swift developers to create the servers they want and need without needing to know another programming language.
The first big three items to be tackled by the Server APIs Work Group will be base networking, security and encryption, and HTTP and WebSockets.
Base networking will cover the essentials of IPv4/IPv6 networking, from socket creation to domain name resolution. Currently, there isn’t a way to create a raw socket in Swift without dropping down into C land. Basically, any kind of networking that a developer may want to do in Swift currently has call C functions of the underlying OS. This is the first step in getting a server-side framework entirely written in Swift.
The next step is implementing all of the security and encryption that the modern Internet relies on. This allows for secure HTTP transport by encrypting the data that is transported between the server and a client. The most commonly used library for handling SSL/TLS connections is OpenSSL and most of the current frameworks for Swift on the server use it. However, Vapor uses LibreSSL, a fork maintained and developed as part of the OpenBSD project, whereas macOS and iOS use Apple’s own library SecureTransport for handling SSL/TLS. OpenSSL and LibreSSL each require the install of a C library and have slight differences in the supported cryptographic schemes and neither are compatible with SecureTransport. With a coherent, Swift-provided mechanism for handling encryption and signing, developers won’t need to worry which schemes are supported by their framework and will know that whatever they use is built to be consistent with the rest of the Swift standard library.
Wikimedia Commons
The final item to be handled by the working group is the handling of the protocols that are commonly used today: HTTP, HTTP/2, and WebSockets. Currently, each framework is responsible for handling its own HTTP parsing, with some using C libraries, and others writing them in Swift. Either way, it is a duplication of effort between frameworks and something a modern-day standard library should provide. In addition, some frameworks support the more modern protocols like HTTP/2 and WebSockets, while some of them do not.
With the Server APIs Work Group working on the foundation needed for server-side Swift, framework authors will be able to focus their attention on more exciting and innovative features. It will also help developers know that their application won’t be restricted from WebSockets or TLS simply because their framework hasn’t incorporated it yet. And it will help end-users by having critical security bugs fixed once in the platform versus in a framework’s dependency’s (dependency’s …) encryption library.
Looking forward, there will be some further challenges for server-side Swift. The largest will be the handling of asynchronous code. Swift currently does not have any built in support for asynchronous vs. synchronous code, it is all handled through Grand Central Dispatch. Without a built-in mechanism like async/await, much of server-side code is going to have to rely on callbacks, which can very quickly lead to callback hell. One framework, Zewo, solves this problem with coroutines, allowing for an asynchronous task to re-enter the calling function at the call site. Another solution is the delegate pattern, but that is tedious and adds boilerplate for most simple tasks. Or will Swift perhaps go full functional and gain monads, allowing for asynchronous operations to be modeled as monads?!
Related: Would Async/Await Work in Swift/iOS?
Another challenge for server-side Swift will be string handling and regular expressions. Chris Lattner has acknowledged Swift’s underwhelming string handling and wants to make it better than Perl, one of the first server-side languages due to its powerful text capabilities. Unfortunately, Swift probably has the worst regular expressions interface in modern day programming languages and its other text processing functions are clunky, to say the least. On the Internet, (almost) everything is text and working with it should be streamlined and fluid.
With the Server APIs Work Group, Swift will start getting the pieces it needs to allow for pure Swift server-side frameworks. Hopefully, with the success of the group’s initial three items, they will continue to influence and create solutions to some of Swift’s other deficiencies. I think this will greatly help move Swift from an Apple-only programming language to a truly platform-agnostic, systems programming language.
