You will need the following software components up and running:

• Vapor Toolbox
• Swift 5
• XCode (11+)
• macOS or Linux

We will assume you are using macOS but all this should work the same under Linux.

You can find all the code for this chapter in the following Git repository: https://github.com/PacktPublishing/Hands-On-Swift-5-Microservices-Development/tree/master/Chapter 2

To write server apps in Swift, we require an understanding of where Swift comes from and how it fits into the world of server languages. Swift was invented by Apple engineers as an alternative to C-derivatives, for example, C++, and, Objective-C, Objective-C++. After initially keeping Swift proprietary Apple then released Swift as open source for macOS and Linux. You might have wondered why Apple would bother to make Swift available on Linux, as Apple doesn't usually release any Linux products (not even iTunes).

Swift was designed to be a native language from the very beginning. It means an application gets compiled into binary code that runs directly on the processor, making it the fastest way for an application to run.

When Apple released Swift for Linux, there was little application. The UI was still functioning only on Apple devices, but a good bit of the essential frameworks, Foundation, in particular, was functional on Linux. These frameworks opened the door for some early web frameworks that took Swift and connected it to C libraries that would allow Swift code to run as a web server.

The Perfect framework was the first framework that did this. In September 2016, Tanner Nelson wrote the first version of the Vapor framework, which was loosely based on the Laravel framework (PHP). In May 2017, Vapor 2 was released, which was the first Swift framework that didn't rely on a C library to provide web server functionality. In the meanwhile, IBM started to work on Kitura, yet another framework allowing Swift to be used for web applications.

In early 2018, Apple released SwiftNIO, which is a network library for Swift. You can think of it as "Netty for Swift" if you are familiar with Netty (Java). To put it simply: SwiftNIO provides a very foundational framework to operate in a network and in files, such as opening connections, sending data, receiving data, sending streams, reading streams, and similar operations.

By releasing SwiftNIO, Apple now gave developers an essential set of features to work on server applications. SwiftNIO, like Swift, was also released for Linux.

Let's take a brief look at the history of Swift in the context of other programming languages.

In this section, we want to take a look at the development of Swift, from Fortran, a very old programming language, up until Swift.

The following diagram and the timeline next to it highlights well how Swift combines the best of numerous worlds:

It stands out that Swift was influenced by Rust, Ruby, Python, Haskel, and C#, making it a very modern language that copied some of the most loved features of the other languages.

Now, we have learned about the history of Swift and where its place is in the world of programming languages. Let's look at Swift's performance compared to other popular web technologies next.

Swift is competing with a good number of frameworks and languages. Some might argue that performance is only one out of many factors that should be considered when choosing a technology. While that is undoubtedly true, think of this: you want to build a project in a way where technology will not hold you back much. Facebook, as well as Uber, has spent years rebuilding and reworking their infrastructure. No matter what technology you choose, you will most likely refactor your application as well. However, having selected a stack that allows you to do so gracefully is crucial.

You could be looking at some raw benchmarks in this section, but I think it makes more sense to analyze with a bit more depth what performance holistically looks like for a project. When comparing Swift to its competition, you want to stay as clean and objective as possible; the following comparisons attempt to assess the situations objectively and as close to the real world as possible.

Almost any website can run with any of the languages available. The question is often not "Is it possible?" but rather "Does it make sense for us?". In some cases, speed and performance are more important than convenience. In other cases, it's the exact opposite.

Let's briefly dig into the following types of languages:

• Scripting languages: PHP, Python, Ruby, JavaScript, and so on
• Virtual machine languages: Java, .NET, and Scala
• Native languages: Go, C, Rust, and Swift

Afterward, you will see some metrics of Vapor, the most popular Swift framework.

Script languages are not being compiled into a native binary but interpreted on-the-fly. So, every request to the server is treated individually and mostly isolated. The server then calls the language interpreter to work through the requested file (index.php, for example). Every time a script is called the server program needs to be started again. Naturally, this is not the fastest way to respond to a request.

A lot of mechanisms to speed up this process were invented over the years. All of them are essentially trying to do the following:

• Cache interpreted code.
• Cache various outputs and inputs as a whole.
• Reduce the amount of overhead.

A lot of optimization for these languages is solely the idea of caching what they have compiled already and then returning it from caches when appropriate. There is principally nothing wrong with this approach, but it makes it difficult to compare performance. You want to assume the worst scenario, which is an empty cache when evaluating the pure speed of an application. Caching can be added later—even to an already speedy application.

The most popular scripting languages include Ruby, Python, PHP, JavaScript, and Typescript. All of them have various environments and interpreters, some of which are faster than others. They all share that they are naturally not compiled into binary code and will consequently always fall behind native languages. On the other hand, they enjoy a rich community and have gained many fans due to their simplicity.

Let's look at some real-life examples of websites dealing with scripting languages.

Facebook started all in plain PHP and over a decade came up with its own PHP-flavored server called Hack. Hack started out as an initial attempt to compile PHP to a native binary file. It failed, however, due to the unforeseeable internal structure of a PHP program (dynamic variables, inconsistencies, and so on). Hack ended up being a PHP version that was modified to fit Facebook's internal needs. However, Hack is now running as a Virtual Machine (VM), not as a native application.

The reasons for Facebook were that it wanted to keep its dependencies and existing libraries operational while also increasing performance. While Facebook shows that scripting languages can certainly get very performant, it also shows how discontented Facebook became over time with PHP.

Twitter started, like Facebook, as a monolithic application. It was written as a Ruby-on-Rails application. However, the increase in traffic caused Twitter to rewrite its backend entirely using the Java Virtual Machine (JVM), which means programming languages such as Java, Scala, and Clojure were used. Twitter also specifically attributes the microservice architecture as part of its path forward with regards to meeting traffic needs.

Uber has transitioned critical services from Python to Go by now. In this case, it was partially for performance, but not in the same way Facebook was affected. Uber needed some of its services to be fast, concretely, live position updates. Uber chose Go because it was able to get better performance.

It is interesting to see how big players have started to transition some of their services from scripting languages to native ones.

Let's explore VM languages next.

The most commonly used language in this category is Java. JVM has a long track record for being an enterprise-class web technology. On the other hand, .NET by Microsoft allows you to write in a variety of languages; often, C# stands out as the most common one for server applications.

Right between JVM and .NET is Scala—which is a new language that can compile into either .NET or JVM.

VM languages have the advantage that they are pre-compiled. They are not interpreted on-the-fly like scripting languages but pre-compiled into VM-specific byte code, which is then run on the VM. It comes with a good performance boost.

Apple, IBM, and LinkedIn are three examples that are using Java in a lot of their infrastructure.

Because VM code runs on the actual VM, and the engine is an extra layer on top of the operating system, VMs typically need a lot of RAM to operate smoothly. It is very common for the JVM to run on multiple GBs of RAM even for relatively simple applications.

Swift is a native language that compiles into native apps! So are C and C++. C (and C++) is inevitably the fastest language because it is so close to machine code (leaving Assembler aside). Many scripting languages directly plug into C for this reason. Node.js, PHP, and Python often directly utilize C functions, and those will always be very fast. Naturally, a pure C server will be the fastest server you could develop.

So, why not write our servers in C, you might ask? The reason you don't necessarily want to do that is that C is not convenient or safe in terms of memory leaks. It is complicated (some say impossible) to write good memory-safe programs in C. For web projects, this problem leads to the creation of Go (sometimes referred to as Golang), Rust, and Swift. All three were invented with the thought in mind to keep the performance of C/C++ but get better memory safety.

Go and Rust kept a mostly C-like functional style whereas Swift got inspirations from other object-oriented languages such as Java and scripting languages such as Ruby and Python. All three languages compile into native code, which means they run faster by default than the other two types of languages. No clear metric would show if any of the three is faster than the others. A good programmer could probably create equally performant programs in either language.

All three languages have been picked up by major players for critical performance tasks. For Swift, big players using it for web services include the following:

• Apple
• IBM
• Mercedes
• Audi

The main reason Swift is exciting to big corporations is that a native application leaves a much smaller RAM footprint. Imagine what difference it can make if you can achieve the same results but only need 25% of your hardware.

As said before, it is not easy to compare languages, let alone frameworks, to each other. One framework might be extremely fast in doing one job whereas completely slow in another position. The following metrics have been recorded with Vapor 3 and a few other frameworks. Take them with a grain of salt, and as technologies continually develop, don't use them as hard numbers because any software update can change the balance:

It shows how all three Swift frameworks perform well compared to other well-known frameworks. You can see that the Swift frameworks outperform the other frameworks, except for Go, quite significantly. The scripting languages do not perform well as they are not natively compiled. The key to performance is that Swift compiles natively and can run directly on the processor.

We have looked at the frameworks and Swift's performance overall, so let's look at some specific Swift features now.

Here is a summary of all of the things that make Swift an attractive choice for server development:

• A modern language built with the modern paradigm
• A native language with native performance
• Very low RAM usage
• Linux-friendly
• Universal usage can create apps for other OSes as well

There are certain situations and ways in which other languages are faster than Swift; however, overall, Swift offers the most significant performance benefits through its native design and low RAM footprint. Let's now explore what Swift looks like on a server.

What does it look like to run a Swift application on a server? When Swift was released as open source, it was released for Linux right away as well. Specifically, Swift favors the Linux flavor, Ubuntu. Hosting a Swift application is very different from traditional web hosting. If you get a web hosting package from companies such as GoDaddy, you will not see them say "Runs Swift 5". Most mainstream web hosters only offer scripting languages. The reasoning is simple:

• Most applications use scripting languages.
• Scripting applications can share the same server.

Swift, on the other hand, as a native language, is the actual web server itself. What that means is that your Swift application is directly responding to incoming requests. Let's look at the following aspects of server-side Swift:

• A self-contained server
• Linux/Ubuntu
• SwiftNIO
• Docker

Let's dive into it.

A self-contained server is a program that does not need another program to run. A PHP script, for example, will run through at least two other programs: PHP (the compiler) and Nginx, Apache, or another HTTP(S) server. A self-contained server such as a Swift application, however, is the only application that needs to run; it answers HTTP(S) requests directly.

Let's look at a small Swift web server:

import Vapor
let app = try Application() 

app.get("hello") { req in 
    return "Hello, world."
} 
try app.run()

Without going into much detail, the crucial part is the last line:

try app.run()

The application does not close; it keeps running. What the framework (Vapor) and the network library (SwiftNIO) are hiding here is that the application is actively listening to incoming connections over TCP on a given port (8080 by default). So, incoming requests are answered directly by the application and, by extension, the return statement.

If you have a background in dealing with scripting web applications, you may find a lot of perks in self-contained servers. In scripting languages, every request is usually isolated. Every request is treated individually, and you have no access to the other requests that are coming in. Technologies such as Memcached are designed to bridge this for you to share information between requests.

In Swift servers, however, the process, the running application, is the same for all requests. You can share memory, objects, and instances across requests. It not only allows you to centralize some of your logic (such as the database), it also saves you a lot of memory and CPU power.

Now that you have learned how a self-contained server operates, let's take a look at the hosting operating system: Linux/Ubuntu.

When Swift was open-sourced, it was delivered Linux-compatible. Ubuntu is the official flavor of Linux that Swift currently supports. Numerous other platforms that are Linux-based are being developed currently; for servers, the best option was and remains Ubuntu.

Ubuntu has been and still is a favored Linux-distribution for server applications way before Swift. A lot of other technologies are running reliably and well on Ubuntu, and so it is not surprising Apple decided to support Ubuntu primarily. Since Ubuntu is also open source and has a large user base, it is unlikely that using Ubuntu for Swift applications will disappoint. Initially, Swift on Linux had some compatibility issues; however, with every Swift version, those have been eliminated.

In the distant future, it is thinkable that Swift applications might run on other platforms, including Windows and it might be another hosting option, but you might ask why you would want that since Linux has been reliable and stable. According to one of Swift's authors, Chris Lattner, "the ultimate goal for Swift has always been and still is total world domination. It's a modest goal."(https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/#in-which-fields-would-you-like-to-see-swift-in-the-future)

So, for a Swift app to run on a Linux server requires a few libraries and tools to be installed—most of which can be done with package managers. As the Swift ABI is still maturing, you will almost always deliver the source code with your app. The server will then compile it into the executable you need for the respective OS version. As time goes on, this might soon change into a more library-oriented approach in which you can compile locally and simply move the compiled file.

To conclude, right now Ubuntu is the most promising and reliable way to launch a Swift application on a server. In this next section, we will explore how to achieve that without necessarily having Ubuntu running.

After looking at the actual OS that will run Swift, let's explore an alternative that allows Swift to run on other hosts as well: Docker.

When deploying your application, you can run it on macOS or Ubuntu. In the world of servers, it is a lot more economical to use Ubuntu than macOS (as macOS is only supposed to run on Apple hardware, whereas Ubuntu can run on any hardware). So, you want an Ubuntu server running for Swift. Let's talk about a popular and essential way to make things easier. Docker has been an upcoming trend over the last years. It is a container system that allows for operation-system-level virtualization. What that means is that you can run applications on your machine as if you have another operating system installed.

Docker containers are packages that include everything to run certain software. For example, the Swift container has everything you need to run Swift applications in Docker. Instead of using separate kernels during virtualization (like many VMs do), Docker uses the same kernel and isolates the resources and RAM for each container.

The implications of Docker are huge, especially for microservices: instead of having to deal with many different servers for an application, it is now possible to only deal with Docker containers. So, particularly when developing a microservices application, it is beneficial to run multiple services in separate Docker containers as they all run on the same hardware. It also allows for an interesting scaling opportunity since the applications operate without needing to worry about the underlying OS. For example, if you need to run 100 instances of one service, you could run it on one big server or 20 smaller services—your application won't know nor notice the difference.

The relevant elements of Docker are the following:

• Images: These contain everything to run.
• Containers: These have image instances that are running.
• Repositories: Like GitHub, these are just for Docker images.

Furthermore, a Docker container can specify how much CPU and RAM it needs. This prevents applications from stealing resources from each other.

Let's now look at the last central piece of server-side Swift: SwiftNIO.

What is SwiftNIO? It is the official library Apple offers for managing and dealing with network connections and data streams, including filesystems. SwiftNIO provides all of the tools, protocols, and features you would need to operate in a network.

SwiftNIO is a big step forward to the server-side Swift world since it standardizes network communication and delivers the tools—in Swift—you need to build performant and reliable network applications. Apple has invested a lot of time and energy into SwiftNIO for it to be the main go-to tool when it comes to the network.

At this point, SwiftNIO is used in all major network libraries and frameworks that are developed for server applications in Swift. The convenient part of it is that framework developers—and by extension, you—don't need to worry about debugging hardly any network issues anymore because Apple has taken that part over.

For all the intents and purposes of this book, SwiftNIO is something essential to be aware of, but it will mainly stay in the background. Vapor—along with other frameworks—build around NIO in a developer-friendly way.

SwiftNIO allows us to operate asynchronously, we can send and receive data without having to worry about the exact timing or the network connection. This leads us to look at asynchronous events in general.

If you have dealt with network connections in the past, you will be familiar with the concept. There are two ways of looking at requests: synchronously and asynchronously.

Synchronously means you send a request (for example, to a server) and your code will wait for a response before it continues. An example would look like this. This is the actual code from a Vapor 2 project:

let user = User()    // User is a model that is connected to a database
user.id = 2          // set some attribute
try user.save()      // saves this model to the database 
print("saved")       // this line is called after we saved

The last line is only called after the user is saved; the whole program waits for the saving process to be finished. In contrast to the synchronous approach is the asynchronous method. The following is the same code, now written for Vapor 4:

let user = User() 
user.id = 2
return try user.save(on: request.db) { _ in 
    print("saved")
}

You can see here that we are returning an EventLoopFuture<User> (line 3), but we are also not printing the "saved" string right after the return statement (because it would never be called), but we put it in a callback function. The fundamental difference here is that deal with the fact that we do not know when the user is saved. The database might be busy or slow; it might take 1 or 10 seconds. But when it is saved, we know that the callback function is called and then we print the "saved" string.

SwiftNIO is all based on the concept of asynchronous events; it handles all of the magic in the background for us, and we do not have to worry about it.

Now, let's look at some of the new features Swift 5 has brought to the table.

You already have an understanding of how Swift works. In this section, we are looking at some of the newest features that Apple has released at the time of writing this book. There are a lot of bug fixes and changes in every Swift update, but the following features are particularly noteworthy for us in Swift version 5:

• ABI stability
• Raw strings and UTF8 strings
• Result type
• Future enum cases
• Flattening nested optionals

There are a couple more interesting new features of Swift 5. However, this section only contains the ones that will be most relevant for server development. Take a look.

One particularly interesting new feature is that Swift is now ABI-compatible with version 5.0 and later ones. It means that libraries, frameworks, and applications could have different Swift versions but remain compatible with each other. As the number of libraries and frameworks for server-side Swift keeps growing, this will be a significant improvement to prevent version locks.

For example, you write your application with Vapor 4.0 and Swift 5, but then a little later Swift 6 is released. Let's pretend Swift 6 is somewhat incompatible with Swift 5. You can then rely on the fact that Vapor 4.0 can be compiled with Swift 5 and your app with Swift 6 while they can still run together without any conflicts.

It also opens the door to deliver applications, libraries, and executables without having to deliver the code. While this is possible already, every compiled Swift application is self-contained and specific to a platform at this point. As ABI stability will be increasingly adopted, it could be possible to not have to compile frameworks and libraries anymore, but just use the delivered libraries.

ABI stability is by far the most important improvement. Next to it are raw strings and UTF8 strings.

Swift 5 has rewritten how it deals with strings internally. Most of it is under the hood and not of practical relevance, but this one has some actual usage: raw strings.

They allow you to write a string that is not interpreted in any way, as in this example:

let rawString = #"This is a raw string with some "quotations marks" that are not being interpreted."#

Earlier versions of Swift would understand the quotation marks as the end of the string, but Swift 5 accepts them now. If you needed to use a variable within a raw string, you could still do that like this:

let age = 27
let rawString = #"My age is \#(age)." // string interpolation happens
                                      // almost like before in raw strings

Raw strings will be useful whenever you have a lot of special characters within a string—like in regular expressions, for example. On the subject of strings, Swift 5 switched from UTF16 to UFT8 strings, which caused a massive increase in performance.

Strings are important in almost every application, and seeing this improve is extremely helpful for us. Next, we want to look at the result type in Swift 5.

Swift 5 introduces a result type for common functions in which the result is either of the expected type or a failure. It is implemented as an enum with only two cases: success and failure.

Let's assume we build a user login and the result might either be the user itself or an error. For purposes of simplicity, let's consider the error in our case would be WrongPasswordError. In a real-world example, there would probably be more errors (timeout, connection, and so on):

func userLogin() -> Result<User, Error> {
    if (...) {
        return .success(user) // assume we got the `user` from somewhere
    }
    return .failure(WrongPasswordError)
}

When we are now trying to deal with a login attempt, we can nicely filter out the result:

switch userLogin() {
    case .failure(let error): 
        // ...
        break
    case .success(let user):
        // ...
        break
}

The nice additional benefit to this type is that it can be used in asynchronous and complex code and allows for standard ways of dealing with errors. As frameworks and libraries adapt to this type, it will allow for predictable error handling.

Imagine you have an enum :

enum ConnectionError: Error {
    case timeout
    case badRequest
}

If you are checking an error from a result, you will do it like this:

switch (error) {
    case .timeout:
        print("timeout")
    case .badRequest:
        print("bad request")
    default:
        print("another request")

As frameworks and libraries develop, the ConnectionError enum could be extended by a future version of a framework or library. Adding another case to the enum could look like this:

enum ConnectionError: Error {
    case timeout
    case badRequest
    case denied
}

If a newer version of a framework updates this, it will cause your old code to select the default case, and you would not even notice that there is a new case. By adding a little attribute, @unkown, to the default case, you tell the compiler to warn you if the switch block is no longer exhaustive. This is a huge benefit to making sure enum cases are exhaustive even when new cases come along later on. Our switch statement now looks like this:

switch (error) {
    case .timeout:
        print("timeout")
    case .badRequest:
        print("bad request")
    @unkown default:
        print("an unkown request request")

The added case for the enum will now cause a compiler warning—but it won't break our code. This is important as this might happen in other external libraries as well. So, you don't need to worry about it in terms of compiling your software, but it is beneficial to be informed about this change. Swift 4.2 would not notify you nor would it break the code.

This addresses a problem where you are trying to get the return value of a function from an object that might be null. For example, we have a Product class that has a getPrice() function that returns an Int instance:

class Product {
    func getPrice() throws -> Int {
        return 10
    }
}
var product:Product? = nil
var price = try? product?.getPrice()

In Swift 4.2, price would be an "optional optional Int" (Int??); however, in Swift 5, we can change the last line to this:

var price = try? product?.getPrice()

And now we only have one level of optionals as opposed to two. While this example is elementary, it is a powerful feature as you might be chaining a lot of optional functions together in a server application.

We have now seen what new features Swift 5 brings; a lot of them are very useful for backend development. In the next chapter, we will look at Vapor, the most popular server-side Swift framework.

In this chapter, you looked at the history of Swift and why it stands out from other languages. You then learned why Swift has been leaning toward server development from the beginning. After looking at Swift's performance compared to other languages and frameworks, you learned about Swift on the server and what is currently supported. Docker and SwiftNIO should be terms you can explain by now. Finally, you explored the features of Swift 5 and have seen examples of what the changes could look like in practice.

Go through the Questions section to validate your understanding of Swift on the server.

In the next chapter, you are going to explore the Vapor framework and you will be set up to create web applications with Vapor and Swift.

To see whether you understood the gist of server-side Swift, try answering the following questions:

1. Why is Swift being a native language helpful?
2. What is the preferred OS for server-side Swift applications at the moment?
3. What is SwiftNIO?
4. How does Docker help?
5. Name three of the added benefits of Swift 5.