How to Think in Server-Side Swift

A New Center of Gravity

In more Copernican terms, Terminal and Swift Package Manager are the twin suns around which the Server-side worlds revolve. It’s possible to develop Client-side Swift projects without using either tool. But both are at the heart of every Server-side Swift project.

The corollary to this is that Xcode is not an essential part of Server-side Swift. This is a huge difference from Client-side Swift. Some Server-side Swift developers choose to omit Xcode and skip building an Xcode project altogether!

Now, if you love Xcode, don’t panic. :] Generating an Xcode project is the Server-side norm. Xcode is, and will remain, a great environment for developing Server-side Swift apps.

But Xcode can’t help you build or run Server-side apps once you switch from Apple devices to Linux, Docker and beyond. You can build, run and test your Server-side apps in Xcode as you’re developing on your mac. However, everything you build via Xcode will be a transient artifact to be discarded when you deploy these apps to Linux, Docker or the cloud.

In fact, you can take this one step further. The entire Xcode project in Server-side Swift is a transient byproduct of core processes controlled by Terminal and Swift Package Manager.

In practice, a common project workflow after creating new assets in Terminal is to run swift package generate-xcodeproj to regenerate a completely new Xcode project file. Imagine doing that to an established Client-side Swift project!

You’ve touched on binaries and frameworks at several points so far. Time to take a look at how frameworks translate to the expanded Server-side universe.

Building a Common Foundation

Swift is a fantastic constant across heterogenous environments. But the Swift code you’ll write isn’t the same everywhere. This is because Swift isn’t an island.

When you write Swift code, you dip into helping frameworks such as Foundation. This is important. It provides an array of critical primitives, types and functionality.

Additionally, its presence helps the Swift Standard Library stay small and highly focused. Simply put, without Foundation, Swift wouldn’t be the Swift we know and love.

It can be jolting to realize that Foundation doesn’t naturally exist everywhere. You shouldn’t take its presence for granted.

In fact, in the early days the lack of Foundation on Linux was a great challenge. A team of relatively unsung heroes worked to implement much of Foundation. This became The Foundation Project.

Thanks to the ongoing efforts of The Foundation Project, you can take for granted that Foundation can do what you need across all Server-side Swift platforms. That said, not all parts of Foundation have been implemented on other platforms. It’s always a good idea to check the project’s current Implementation Status page to see if the part of Foundation you’re planning to use is present beyond Apple’s platforms.

Remember, when you take Swift beyond its Apple-native box, you should make sure all the frameworks you’d like to use will work.

Choose Wisely, Grasshopper

OK, it’s time for a quick confession:

In the early days of Server-side Swift, a foolish grasshopper needed a specific piece of Server-side functionality for a Server-side project. He blithely grabbed a nice-looking macOS/iOS framework from Github without much thought.

“Sure, it doesn’t have a Package.swift file,” I thought. “But I’ll just throw in a simple Package.swift file for it and be done. Am I clever!”

The grasshopper discovered that while you sometimes can to adapt a package for Server-side, that’s not always the case. This is especially true if a package has nested dependencies on platform-specific tools.

The grasshopper learned to respect the differences between Apple-only and heterogenous environments. He also learned to take this into account when making architectural decisions. Learn from the foolish, fellow Server-side grasshoppers. :]

Part of the reason for such foolishness was the lack of available frameworks. These days, extensive sets of packages exist for both Kitura and Vapor .

Still, within any web framework there are cases where you need to reach beyond officially supported frameworks for a piece of functionality. So, how do you determine if a promising-looking framework will work Server-side? The choice comes down to a few simple questions:

• Does the framework have a valid Package.swift file? If not, don’t pull a Brian®. Just say no and check out the another option. Otherwise, keep going.
• Does it contain any mac-specific dependencies, either via Carthage or CocoaPods, or nested directly within it? If so, again, get outta Dodge now! Otherwise, proceed, grasshopper.
• Are all primary and secondary dependencies also available on Linux? When it’s time to build your project beyond the Mac, will the Linux Terminal be able to retrieve them using apt-get?Linux users can check this by running apt-cache search <keyword> . They could also use via a package manager like Synaptic).

If a framework clears these hurdles, it’ll make the leap to compile beyond Apple platforms. Again, on the majority of server-side projects, this likely won’t be an issue. But a little understanding about what’s needed for a framework to go beyond Planet Apple goes a long way towards thinking in Server-side Swift.

A Copernican Revolution

The shift from Apple-controlled hardware and operating systems to a broader universe leads to several changes in architecting and building out Server-side Swift applications. Paradoxically, this might seem like either:

• No Big Deal: It’s just a few things to do differently. Otherwise, don’t worry about it.

or

• A Very Big Deal Indeed: If you really think about it, you’re in a whole different universe here.

So, which point of view is right? As you may have guessed, the answer is both. :]

The best way to understand the subtle differences between Swift’s Server- and Client-side worlds is with an analogy to The Copernican Revolution.

In Copernicus’s time, common sense knew that the earth was at the center of the cosmos. The sun, moon, planets and stars all rotated around the fixed foundation of the earth. This is like the Xcode- and Apple-controlled cosmos that Client-side apps have inhabited.

Of course, Copernicus realized that sun was at the center of the cosmos. Thinking differently opened new possibilities. It became easier to reason about and resolve long-standing problems.

Ultimately, new realms of discovery and exploration opened that simply weren’t possible before.

This is the perfect model for thinking in Server-side Swift. The expanded universe of Server-side Swift asks you to change the way you think about Swift and Xcode. In exchange, it opens new possibilities that can enhance your Swift skills and apps.

Like the original Copernican Revolution, nothing changes. And everything does.

Copernicus’ critics scoffed that his discovery changed nothing practical from day to day. People still went to bed, woke up and performed the same tasks they always had. Shifting the center of the cosmos from the earth to the sun changed nothing.

This is true in a post-Xcode-centric Swift world as well. Xcode still works when developing for Server-side. Other than a few small workflow changes, nothing looks much different on the surface.

But there are advantages to expanding your thinking to include changes brought by Server-side Swift. It gives you greater insight into why we do things differently when targeting the server.

You gain the simple but essential tools you need to leverage Terminal and Swift Package Manager. Similarly, it gives you the tools to choose and then implement frameworks on your Server-side projects.

Beyond these pragmatic benefits, it’s important to appreciate the work that went into Foundation, Vapor, Kitura and any other framework designed to build and run cross-platform. You rely on that work every time you write a line of Swift that uses these platforms. It’s amazing that in a few years, Swift has grown from a proprietary Apple-only language to a cross-platform tool with a broad and growing scope!