How to organize the backend of a mobile application?

What are we doing? User registration and authorization service for a mobile application

In pet projects of each mobile developer, sooner or later there comes a time when you need to quickly and without too much headache create a server for your application. It does not matter what function the server should perform: whether it is data storage or user registration / authorization.

As a rule, in the beginning everyone goes (well, or most) along the path of least resistance. We are looking for a turnkey solution and see how quickly it can be adapted to our needs.

At this stage, the first thing that you can “google” is Firebase services, the free limits of which are more than enough to organize the backend of a small mobile application. But in this case, considering exactly the Russian developer, we risk stepping on the rake of our legislation - cross-border data transfer and storage of the user's personal data.

(Federal Law 152 “On Personal Data”, Article 12, Chapter 2) The

temptation to use Firebase is great, but if we want to insure ourselves against unnecessary fuss with various supervisory agencies, we begin to look at alternative options.

The next stage is the use of a VDS server with some kind of open-source or freemium solution, where the ready-made “service-as-a-service” or a solution allowing to deploy similar functionality is taken as the basis.

Several years ago on Habré I already wrote a detailed BaasBox setup guide (the article was removed from the public due to outdated information) on a rented server and gave an example of using various calls in the iOS application for the Objective C language. But BaasBox is really “heavy weight” and dictates your minimum for a rented server. Having played a little with him, it was decided to use a different solution. At that time, the Parse-server was only recently put into open-source development by Facebook, it did not have as many adapters as it is currently, but its capabilities were more than enough for personal projects and applications of private customers (many projects are still exist and work stably).

In fairness, it is worth noting that parse-server has matured very much and is actively developing. At the moment, almost all the functionality that was available in a commercial ancestor has been recreated. You can write your own hooks, localized push notifications, a process manager, and there is even a subscription for changing objects based on sockets (ParseLiveQuery - if it’s interesting, I’ll write a separate article on setting up ParseLiveQuery).

But parse-server ceased to be interesting precisely at the moment when it was required to implement a non-standard data type, which is difficult to work on the basis of types defined in the system. It also interferes with the fact that, not being a specialized server developer, I previously did not attach importance to more efficient deployment of the environment and many configuration files were made by hand, while the actions were constantly repeated on each new server. It is at this moment that the understanding comes that a boxed solution is not a solution to all problems, and you should proceed to the next stage of organizing your server for a mobile application.

Recently, my main development language is Swift.Therefore, it is he who is of interest to me primarily in writing server-side code. Swift itself is easy to install on a unix system, but it will not give any obvious advantages. At its core, it will resemble the development of a console application with complex logic. It will take a lot of time to recreate the basic methods required in the server.

As in many other languages, server side swift has its own frameworks and communities involved in the development of these solutions.

At the moment, there are three most significant solutions for developing server side swift:

• Perfect
• Vapor
• Kitura

There are other options, but they are not worth mentioning because of their long-stopped development and their death.

In terms of documentation and support, I like Vapor more, but it's a matter of taste. Other solutions will be close to someone. One way or another, in many moments they are similar.

Naturally, further throughout the cycle of articles in my examples I will use Vapor. Based on it, we implement the user registration / authorization service, sending and confirming email, the ability to reset and change the password.



Is it worth doing an implementation without practical benefit?

Probably no! Therefore, we will make the most adult service that you can take and use to organize the logic for storing user data on your server.

If the decision is adult, then it entails the use of deliberate decisions. We must simplify the scaling, implement data validation and provide for the storage of the user session, so as not to force him to enter his username and password each time.

What do we need for this?

• VAPOR 4 (yes, still in beta, but the release is coming soon, as the developers promised)
• PostgreSQL (there is an excellent adapter for working with this database)
• Nginx
• SSL (close all our requests from the client to the server using a certificate)
• Localhost (consider the development method locally, so as not to get attached to the network and work on the road without any problems)

Well, we will pack all this in Docker to ensure the same work, independent of the current runtime environment.

Honestly, I was skeptical of the docker at one time, but I should have looked more closely at this technology. The purpose of the article is not to explain his work and to learn how to work with him (I suspect that I myself still have to learn many interesting features of the docker). But those who don’t know what it is and how to work with it, can independently get acquainted with Docker through the official link: www.docker.com

Looking ahead, I’ll leave a useful link to the Kitematic application, which is designed to simplify the work with docker containers : kitematic.com (must have for those who do not like to use the terminal).

So, let's start by installing Docker on a mac-computer: Follow the

link hub.docker.com/editions/community/docker-ce-desktop-mac link and download Get Docker Desktop For Mac (Stable).



Open the resulting image and then install nothing differs from the standard copying of the application to the program directory.



After that, just start the application and wait until the service is fully initialized.



If there is no Docker ID yet, then it should be created on hub.docker.com. And if there is, then simply log in to the application.



That's all, the preparation for using Docker is complete. It remains only to check the current version and information about the environment.

> docker version


> docker info

This completes the preparation for the development of the authorization service. In the next part, we will see how you can use containers of various services, we will deal with docker-compose to automate the assembly of our environment and begin to write code.

PS: A little advice from personal experience. When we develop services on our local machine, Docker allocates default resources for our use. If we want to visualize the expected behavior of the service on a remote server, we should take care of the resources on the local machine, as close as possible to the characteristics of the server. You can do this in the settings of the Docker Desktop application, which we downloaded:



Article author:
Vitaly Podolsky, HackerU teacher