CocoaConf DC 2016: Swift server side
In September 2016, iOS-developers of our R&D partner NIX Solutions attended CocoaConf DC conference in Washington DC where they received a lot of useful information. They listened to many lectures on different topics of different levels of complexity. In this article we would like to tell you about one of them, which grabbed their attention because of its unusualness and novelty—“Creating a Server Side Application with your Favorite Language: Swift!” by Jonathan Guthrie (Twitter, Github).
Jonathan is one of the developers of Perfect—a framework that allows the use of Swift language in developing of server side applications. This topic is very interesting for many iOS-developers because most of the “home” ideas are shut down due to the problem of server-side realization. But at the same time learning additional languages or attracting people “from the side” doesn’t bring much enthusiasm.
The emphasis in the article is put on the theoretical part of the question and not on the code. Practical guidelines can be found in the “additional materials” section or in the search engine.
The second advantage is the fact that the language has static strict typification, which means that the final types of variables and features are determined at the stage of compilation and the language doesn’t perform default transformations. Thereafter, we can diagnose the problems such as dividing a line by a number almost instantly.
The third important aspect is RAM usage. It can seem inessential and probably many of you have heard phrases like “we just need to buy more hardware” from back-end developers but while executing the same code (Benchmark), Perfect framework requires a lot less resources than Node.JS, Java, or Ruby.
Why is it actual? The answer is simple—the price of cloud hostings. For almost all vendors, the most important criteria influencing the price, is the amount of cloud RAM. Surely, with the more expensive billing plan you are also given additional CPU capacity but John assures us that in practice the reason for choosing a more expensive billing plan is exactly the memory.
For example, Amazon offers such billing plans:
|4 vCPU, 16 Gb ($0,239 / hour)||$172,08|
|1 vCPU, 1 Gb ($0,13 / hour)||$9,49|
If our server will “fit in” the restrictions of RAM we can have about 18 balanced exemplars. This is a nice thing for small startups and developers who, for whatever reason, are no longer satisfied with free plans.
Perfect framework doesn’t require a lot of memory under load or while executing (Benchmark) which is especially beneficial while using micro service architecture.
John also noted the possibility of isomorphic programming. This is an impressive idea—using the same code for describing domain zone and business-logics. This would let developers repeatedly use a ready tested code, which means speeded up production and reduced amount of bugs and as a result, shrunk expenses and better code quality. On the other hand, it all sounds great in theory but in practice, this approach is not that simple and has a lot of underwater rocks so we should take this statement with a pinch of salt.
Another good sign for developing Swift in terms of server side developing is a healthy competition between frameworks. Among alternatives to Perfect, you can now find these on the market:
Kitura was created by IBM and its developers officially declared that they will do their best to place Swift-services on their cloud platform IBM Bluemix.
Other pros and cons of each of them are described here.
The area of Swift usage is widely expanding. Jonathan claimed that although developers are competitors, they all keep up with each other really well, often discussing release of certain parts and aiming for more and more frequent usage of Swift language in the future. Apple is also a major player in this market and they have a Server APIs core team that includes not only their own developers but also technical experts from the above-mentioned companies. Core Team Manifesto: https://swift.org/server-apis/
The team works on these problems:
- Basic work with the network
- Security and encryption
- HTTP and WebSocket
This will help an ordinary Swift-developer in many ways:
- Library developers will write less of their own abstractions which will lower the learning curve for alternative framework.
- Easy to replace (or even combine) solutions from different libraries.
Jonathan and his Perfect team developed a Perfect Assistant tool which has an extremely intuitively understandable graphical interface.
It allows one to:
- Easily manage the projects.
- Easily add makedepend to the project.
- Check the project operativity, not only under OS X but also under Linux.
- Set up and maximize projects on Amazon S3 and Google Cloud Platform.
This utility is very helpful for developers who are only beginning to get into the server side development. A tone of technically difficult problems—server launching or expanding—are solved within several clicks.
We think that writing additional graphical interfaces is the right direction to go because it will keep “the fire in the eyes” of people who are interested and enable the Swift-serve side development community to continue to expand.
Using Swift language for server side development can be called a perspective idea, the popularity of which will only grow. Reasons:
- Great results in productivity and memory usage.
- The community will only grow thanks to availability of a great amount of guidelines, ready modules, and development of additional tools.
- Main frameworks developers gained the support of Apple and decided to solve common problems together which beneficially affects the whole Swift ecosystem.
- Interest in this idea from such great companies like IBM.
Unfortunately there are some cons which at times prevent developers from using Swift in the production:
- Production for Linux has its specifics. Some frameworks (Foundation, GCD) are not ported yet so developers have to use libraries written for C.
- Swift language standards are still actively developing and don’t always have backward compatibility.