How to Think in Server-Side Swift
Server-side Swift opens exciting new worlds to Swift developers and best of breed frameworks like Kitura and Vapor expose the full power of Swift. In this post you’ll learn the key differences between Client- and Server-side Swift environments, and how to use them to take better advantages of Swift in its Server-side form. By Brian Schick.
One More Thing®
As I wrote this post, WWDC 2019 delivered several new developments. These included Xcode 11’s new integrated support for Swift Package Manager.
Conceptually, this doesn’t have any impact on what you’ve learned here. But practically, Xcode 11’s SPM integration promises some nice streamlining of practical workflows.
Here’s a couple of quick teasers:
First, in Xcode 11 beta you can now choose to create a new Swift Package project:
When I create a quick Package, I’m presented with a sample Package.swift file. Even better, I’m presented with a new hierarchical visualization of the assets specified in the left-hand Project Navigator.
Now I’ll pop in my simple Kitura Package.swift from the Copernicus sample project. It’s a revelation to watch Xcode 11 beta sequentially analyze its contents and recursively nested dependencies.
It then retrieves and assembles these frameworks. It even creates a Package.resolved file on my behalf.
I won’t pursue this further here. But, I’m exciting to see how the deep integration of Swift Package Manager into Xcode 11 will impact real-world Server-side Swift workflows.
Where to Go From Here?
Thinking in Server-side Swift isn’t a big leap. Consider the platform’s breadth and think about what you’re asking your Swift code and tools to do. As a result, you’ll write better, more efficient code that works with the Server-side world.
What do you think? Is the expanded world of Server-side Swift, like much of the recent WWDC, a bit of a mind-blower? Or does the continuity of Swift make it feel more like business as usual from your perspective? Let us know in the comments, and happy Server-side Swifting!