Get an understanding of what server-side Swift is and why it's important.
- [Instructor] When Swift was introduced by Apple, it was meant to be a modern replacement for C-based languages. Over its early iterations, it was primarily focused on Darwin systems so that it can be used for development towards macOS and iOS apps. However, in December of 2015, the Swift language and its supporting libraries, debugger, and package manager went open-source and in doing so, allowed for projects to be built on Linux and other platforms, such as Windows and even Android.
Application of the Swift language would be soon changed once the community got its hands on it. When working on an application, it's quite often that the need for a server-side component would arise, wether it's to store data, perform analytics, or provide levels of communication, servers become an integral part of the apps ecosystem. Usually, when working with server-side components, it requires working with different languages and having to continuously iterate and translate your ideas from one language to what could be a number of others can cause frustration and downtime.
It can lead you to be repetitious in your code as different platforms would require key components to have to be rebuilt in their respective native languages. This is where having one language to work across the entire stack can prove to be helpful. When open-source Swift became available, one immediate role to fulfill was to have it run on the server, so Swift became packaged with all of the necessary system libraries providing users with the necessary foundation building blocks and data structures.
In making it portable from platform to platform, this allowed developers to choose the right tools to build for the server using the same familiar constructs one would be using. The Swift tool chain is an elaborate one where you get the protocols, structures, and types that you'd normally get when you're working on a Swift application but it goes further than that. You also get Foundation, Dispatch, and XCTests, which allow you to build and maintain the same code across different platforms using the same APIs and this turns out to be huge for developers as you're given a way to use one language while working across your apps technology stack.
So you can develop on your Mac and deploy to Linux and as we'll get into in a later lesson, you can even develop the same server-side components using Xcode and build and test as you would with your macOS and iOS apps. However, not everything you're used to having at your fingertips came along with the open-source Swift package and this design decision came because of two reasons. First, some things just didn't make sense in a cross-platform nature.
And the second is the simple fact that some things are better served by allowing developers to build their own unique and specialized tools for the problems that they're trying to solve. One of the things that didn't come over is the user interface piece. This means that you don't get UIKit or AppKit in the open-source Swift package and this is due to the nature of user interfaces themselves. On iOS and macOS, you have UI objects that are built specifically for those platforms and on the web, you use HTML and CSS to do the same thing.
Instead of porting over a UI tool set that may or may not make sense for the intended platform of deployment, the choices made to allow the developer to use the native means of the platform to accomplish UI related tasks. So, when breaking down functionality to develop, it's important to implement a design pattern that separates out the necessary component so that they remain independent of one another. Doing so will allow you to maintain interoperability across platforms while implementing the correct UI components for your intended targets.
So, with open-source Swift growing, it's only natural that the availability of ready-made frameworks would present themselves to developers as options to use to speed up their development time and so there are a number of frameworks that are available that give you access to server-side components so that you can build and deploy your own web services. IBM created the Kitura framework. There is the Perfect framework, which is brought to you by PerfectlySoft and you have the Zewo framework, as well as others.
In this course, we're going to focus on a popular and well supported framework called Vapor, so let's move on to our next lesson where we'll get in understanding of the Vapor framework and see why it's our tool of choice for building Swift-driven web services.
- Reviewing the concept of server-side Swift
- Installing Vapor in a local environment
- Creating a new Vapor project
- Reviewing Vapor's built-in capabilities to interact with external services
- Registering and authenticating with the Dark Sky API
- Working with Leaf templates
- Setting up a Heroku account
- Using common troubleshooting techniques