Did Swift turn into a full-stack development language? When?
At WWDC 2016, Apple officially announced the release of Swift frameworks for server-side programming. This was a big deal since earlier Swift took care of client-side programming. Back then, Node.js was used for server-side programming. In fact, even now, a majority of server-side developers use Node.js. With the introduction of Swift frameworks for server-side programming, things are changing for the better. Perfect and Vapor are two of the most popular web frameworks for Swift, each having its own set of attractive features. It is worth noting here that the language Swift itself isn’t too old. It was released at WWDC 2014.
Available Server-Side Swift Frameworks
Server-side Swift frameworks each have their own set of interesting features. The top frameworks are Vapor, Perfect, Kitura, and Zewo. So let’s dig into what each of them has in store for you:
Zewo
Inspired by Go, Zewo strives to use concurrency while it avoids callbacks much like Go did. It has an MIT open-source license and is fast to use. Zewo has all the basic features one might expect from a server-side framework. If that isn’t enough for you, you can even use middlewares in it. HTTP request/response, TLS (SSL), URL routing, Websockets, Mustache, and JSON are just some of the features it has to offer.
It supports Turnstile authentication framework for logins and sessions, and also supports JSON Web Tokens through its native package. For MySQL, RethinkDB, Redis, and PostgreSQL, it has some connectors. In fact, it even has an ORM for Postgre.
Zewo has samples and examples for the beginners to get to know about how to go about working on Zewo. It has an informative documentation which is a little more than a getting started guide. This might seem like a little too less to start with but it is enough for anyone to start off with Zewo. It is that easy.
Kitura
Developed and supported by IBM, Kitura is one of the best server-side Swift frameworks available in the market. It has the standard features that Zewo has. In addition to that, it has some advanced features which take things further. One notable difference between Zewo and Kitura is that Kitura lacks support for non-native JSON structured data. But what it does support is Aphid MqTT(IoT Messaging).
As far as authentication is concerned, Kitura projects mainly rely on Kitura-Credentials. It has pre-built middleware for CSRF and CORS too, as well as login wrappers for Github, Facebook, and Google authentication (third-party login wrappers).
It is pretty unique in its approach towards databases. For SQL databases, Kuery is used. Kuery is a SQL database abstraction layer unifying subtle differences into a single API. This extends support for MySQL, PostgreSQL, and SQLite. It supports Redis, ScyllaDB, CouchDB and Apache Cassandra too through native packages not related to Kuery. It aims to be an abstraction to SQL instead of a full ORM in order to make more Swift-y native SQL queries.
Kitura even takes things further by having templating not only for Mustache but also for Stencil and Markdown. There is additional support for FastGCI, which allows streaming of data using current Apache servers. If we dive a bit deeper, they have a native connector for using Watson API Services like Weather Analytics, and an HTML5 entity library, which, as you might know, is handy.
As far as deployment is concerned, Kitura is compatible with native Swift environments in macOS and Ubuntu 14/16. Being a part of IBM, Kitura gives you a native macOS app which directly integrates into IBM’s Bluemix platform. For those of you who already Bluemix as a host, this has a lot of obvious benefits for you.
When it comes to learning Kitura, there is no shortage of educational resources for learning it. Its website has an awesome getting started guide. It also has a full breakdown, on the website, of functions included in API. A separate organized section for tutorials and additional guides can also be found on Kitura’s website.
Vapor
This is the second most famous server-side Swift framework available. Vapor has a simple syntax, but if you run into problems, you can reach out to its enormous, highly active community. It is the only framework in this list which focuses on being written purely in Swift. It uses the MIT License and is owned and run by Qutheory, LLC.
Being a Swift exclusive framework, Vapor is a bit different. Swift exclusivity makes it very readable and understandable and also removes the dependence on third parties. So now you don’t have to rely on the HTTP parser provided by Node.js, you can use Vapor’s own Swift parser. It does have to sacrifice on the speed a little but that isn’t a problem since speed isn’t the most important factor in choosing a framework. Sacrificing on the speed allows it to be focussed on being simple, readable and to keep the conventions and protocols in line with the language. It can be said that it is as proud of being written exclusively in Swift as Zewo is passionate about Go-style concurrency.
It has a great set of core features. While it lacks on features like native XML, FastCGI support and CSRF middleware (all of which were present in Kitura and Zewo), it has expanded many features such as support for SMTP for sending emails and Apple’s Push Notification Service.
Vapor has a strong and thorough database support. It has native support for MongoDB and Redis in addition to having native connectors for SQL languages including SQLite, MySQL, and PostgreSQL. Vapor also has the Fluent ORM system which supports MySQL, MongoDB, PostgreSQL, and SQLite. Fluent’s drivers are protocol-oriented being entirely focused on a well done Swift API, This makes it easy for you to add your own protocols if you have some knowledge about Swift and the database you wish to work with.
Turnstile is baked into Vapor. You could use it easily without having to include it as a dependency. With an entire crypto library as a separate, native repository in addition to native frameworks for a variety of tasks, Vapor is as secure as it gets. It also has pre-built Fluent ORM handlers for storage in databases. It also has CORS support available as a pre-written middleware.
There are plenty of features which are exclusive to Vapor. Their templating engine and support for Mustache and Markdown is unique. They have their own templating system called Leaf which is native to Vapor. Being natively Swift, Leaf integrates in a way that fits into Vapor’s engine. Vapor’s route type validation system is quite unique. With Vapor, you can have routes which only work when passed a specific data type. Another unique feature of Vapor is SwiftyBeaver integration. It has a suite of command line tools for the creation and manipulation of projects installable via shell or through homebrew tap. Vapor’s command line interface is yet another feature unique to Vapor.
When it comes to deployment with Vapor, it is similar to the previous frameworks. It has Docker containers as well as helpers in the ‘Toolbox’ command line utility which helps in running Vapor on Heroku and in building Docker containers.
There is a host of resources out there to learn Vapor. The documentation available on their website is easy to use and well organized. It isn’t exhaustive yet though so you might have to look for a few thing in the GitHub repositories. They have their own video library at http://vapor.university. If you’re one to learn through projects, there are a lot of example projects available on Vapor’s GitHub repository. They even have a minimal documentation in Chinese.
Perfect
Perfect is loaded with features. It is big, powerful and fast. Run by PerfectlySoft, a Canadian startup, it’s team has an entangled history with Apple. Some of the members of the Perfect team come from Lasso language’s original team. Lasso, if you don’t know, is a programming language Apple once included in its lineup.
It has an enormous amount of repositories. In fact, the numbers are so large that they had to divide them into different GitHub teams on the basis of the purpose. Perfect has all the basic features including routing, websockets, Mustache, Markdown, TLS (SSL), logging, etc. It has some extras as well which are found in other frameworks, such as MqTT, Apple Push Notifications, XML, and SMTP. Look it up from start to the end, and you’ll fail to find a single basic feature that Perfect lacks. It has a native Mac app but doesn’t have command line tools.
The Perfect community is large and active, much like Vapor, and is hence one of the largest communities in these frameworks, second only to Vapor. Perfect has quite a variety of database support. It comes with native connectors for SQL languages like MariaDB, SQLite, PostgreSQL, and MySQL. It also supports MongoDB, CouchDB, Redis, and FileMaker. Perfect has a partial implementation of Microsoft’s ODBC which is a low-level API which allows you to access multiple database types with one interface.
For security and authentication, it has Turnstile. You can even find Perfect implemented Turnstile versions which extend vendor implementation. Like Vapor, Perfect has its own crypto library in addition to Active Directory, SPNEGO/Kerberos, and LDAP. It has a native OAuth2 library providing pre-written implementations of famous third-party logins like Google, Facebook, LinkedIn, Google, Slack, etc. It even supports basic HTTP authentication, which is noteworthy.
Perfect has some unique features such as its native cURL wrapper which allows the use of libcurl in Perfect. It has robust support for working with directories (create, delete, list), zip, unzip and files (create, read, write, delete). It is the only framework in the list which supports MariaDB, ODBC, and FileMaker. Since Perfect puts a lot of efforts in the unique features that it has, it takes pride in every unique feature that it brings to the table.
It has a variety of deployment options and educational resources. An entire GitHub organization with almost two pages of example projects are out there to help users on a variety of topics. For those who speak Chinese, there is translated documentation as well. Video tutorials are in an abundance as well. It also has a comprehensive and complete getting started guide.
Server Side Swift Frameworks vs Node.js on Benchmarks
Why Was Node.js Prevalent Earlier?
Node.js was prevalent earlier mainly for the following reasons:
JavaScript
JavaScript is one of the three biggies internet is based on. It is the programming language most web applications use on the client-side. To use it on server-side would mean that the developer would be able to apply his/her JavaScript skills on both sides. Node.js made things easier for the developer since if you’re a web developer, the likelihood of you not knowing how to work on JavaScript is close to Pain killing Jiraya if he wasn’t Jiraya’s student. Don’t watch anime? Well, anyway, Node.js gives you a lot of power by allowing you to use JavaScript for server-side programming. This was one of the many reasons why Node.js was the prevalent server-side scripting language.
Asynchronous and Event-Driven Architecture
Node.js supports asynchronous events, ie, your server would react to events and would send events without blocking any other processes, in this way, we can use our resources(input, output, CPU etc) in an optimal manner. Unlike other web application technologies like JSP, Spring, ASP .Net, etc which follow Multi-thread Request-Response, Node.js uses Single Thread Event Loop Model to handle multiple concurrent clients. Node.js uses V8 engine, which is the engine upon which Google Chrome runs.
Real-time
Being fast and scalable, Node.js can be used to develop real-time applications such as chatting applications and live-streaming applications. Its single threaded model is very helpful when our priority is to handle multiple client requests. Another reason to use Node.js for real-time apps is the fact that it allows you to share and reuse packages of library code. If you come across any problem, Node Package Manager (NPM) helps you with more than 50,000 packages, thus making it easier for you to update, share and reuse code. And did I inform you about streaming in Node.js? Node.js tackles I/O bound tasks rather well since it is event-driven. Being UNIX pipes, the streams make reading data from source easy. They also pipe the source to the destination.
NPM
From a developer’s perspective, one of the biggest advantages of using NPM is the fact that it acts as a local package installer. It allows you to choose between local (default choice) and global installation. If you go for local installation, the packages are installed into the ‘npm_modules’ directory inside your app’s directory. Locally installed packages are automatically made available to the running app to ensure that no conflicts occur with packages of other apps. In case the npm package has other dependencies, the dependencies are installed into the directory of that package and not into a shared one. So no more dependency conflicts! Packages providing command line tools can still be installed throughout the system if you use the ‘-g’ flag. This approach, of course, leads to duplication of packages on the filesystem, but considering the size of current hard drives, it isn’t much of an issue.
Why go for server-side Swift frameworks?
Productivity
Gone are the days when you had to employ multiple employees for handling the stack. With server-side Swift frameworks, you no longer need specialists for handling the frontend and the backend separately. Instead, a single developer could handle both backend and frontend using Swift. Thus the time taken by development teams to build end-to-end applications reduces. Since the members provide end-to-end solutions, their knowledge-base goes way deeper than it would’ve been had they used any other framework. And that is the best part of using server-side Swift frameworks.
Performance
You’ve already seen the benchmarks and how server-side Swift frameworks have performed in those benchmarking tests. Such a great performance naturally reduces costs when we deal with providers of cloud-services who charge according to the CPU usage and the memory usage. Moreover, when IBM sets foot into anything, there are a lot of advancements in it. There is a lot of research and development that is being carried out on server-side Swift frameworks, so you can rest assured, there would be a lot of improvement in the performance of server-side Swift frameworks.
Pros and Cons of Working on Server-Side Swift Frameworks
Who Works on Server-Side Swift Frameworks?
The teams of each of the aforementioned frameworks are working on them. But if you’re wondering which mobile app development company is using these frameworks, BrainMobi is. We are a leading mobile app development company. With a team of more than 60 mobility enthusiasts, we develop next-gen apps. Next-gen apps call for next-gen frameworks and server-side Swift frameworks are nothing short of next-gen. So pen down your requirements and send them over to us at sales@brainmobi.com and get a free quote on our idea!
