Tips For Developing A Mobile App Backend

We are in 2021. That means that microservices, multiplatform applications, SPA’s, and ultimately the creation and reuse of scalable architectures, are in high demand. You may be wondering: What does this have to do with a mobile app? Well, very simple: if today you need to have a mobile application that competes in the market, that is capable of attracting an audience and generating traffic that later translates into conversions for your business, you need to consume and use external services.

What is an app backend?

This is where a backend comes in. Traditionally, a backend has always been thinking so that its development goes hand in hand with the frontend, that is, that once a website, a mobile application, or any other system is served, it does not have to make constant requests to external systems that could slow down the user experience.

This is fine for systems that only intend to display static content (little or no changing static information), but when developing an advanced application with push notifications, location-based recommendations, constant user interactions, up-to-date information, and capable to react to external actions; This is where modern paradigms come in, the use of REST APIs and the reuse of systems that can offer data to a wide variety of applications.

Factors to consider when creating the backend of your app

In any case, the success of a backend (regardless of which application is going to use it later) depends mainly on its response speed, although other factors will have to be taken into account so as not to undermine the basic principles of security, scalability and stability.

Authentication and security

Nowadays, two authentication systems are used mainly: a traditional login / registration, or one that relies on the use of social networks (Google, Facebook, Twitter, etc.). If we opt for the second option, we will be able to rely on the infrastructure that these external systems already have, but we will not have full control of what is being stored and modifications depending on the needs of the business can end up being costly. On the other hand, opting for the first option (as long as it is implemented correctly) is usually the most scalable way in the long term, since we will have total control over the data, its architecture, and, therefore, its architecture.

This translates into something very concrete, widely used, and very robust: OAuth 2.0 and an authentication system based on Json Web Tokens (JWT). This mechanism allows us to have a scalable system (more emphasis will be placed on this later), fast and secure, but beware: the information stored in a JWT (if no additional measures are taken) can be easily read and, for that reason, never you have to store sensitive information in them. If you wanted to increase the security of this mechanism, perhaps it would be a good idea to encrypt it with some type of key that both the backend and frontend knew, although it would have to be rotated from time to time to avoid brute force attacks and, therefore, greater maintenance to future.

Scalability and speed

Although it may seem that these two concepts do not go very hand in hand, I believe that, on the contrary, a backend that takes a long time to respond will not scale correctly, although it is true that additional measures will have to be taken at speed to get good scalability.

A first step to achieve these objectives is the concept that the backend must be “stateless”, that is, the information necessary to resolve said request must be included in each request. The server does not have to save any type of information necessary to resolve consecutive requests. This helps that requests are resolved quickly and processing capacity can be scaled across multiple machines without the need for additional configuration.

Another interesting idea would be to separate the logic into different microservices. For example: if we have (as will be usual in a mobile application) a party in charge of registering a user to receive push notifications and send them, it would be interesting to separate all this logic in a microservice (although behind it it uses cloud services such as AWS or Firebase) .

In any case, all these interactions should be transparent to the application, that is, an application would not have to know how many services a backend has behind. This is why, although there are external services, the backend must act as a “middleware” for them. In this way, any type of modification of the service or its extension will be made in a transparent way to the user.

Stability and future-proofing

All the previously mentioned topics are very necessary if we want to be able to attend to the requests of mobile applications, websites or other platforms, but what happens when we suffer a failure or “bug”, an attack or simply the external services stop responding? In that case, the main thing is to find out the cause of the problem, solve it and put our backend back into operation, but for this we need monitoring tools, continuous integration, automatic deployments and, above all, a quality of code that will minimize the risk. of appearance of these questions.

In order of priority, the first thing is to start with a good code analyzer to get used to using good practices and thus avoid the appearance of problems in the future. For that we have tools (known as “linters”) as complex as SonarQube to simply real-time code analyzers that will provide us with suggestions, example: JSLint or TSLint for applications (frontend, backend, etc.) in Javascript or Typescript respectively.

In any case, these tools need a series of “rules” to be useful, so it is important to look at guides and good practices that are widely used, such as Airbnb’s code guides for javascript (yes, that famous company of vacation rentals).

Once we are clear that our code follows certain established standards, we must be able to have a controlled deployment environment, to avoid introducing any human error in it. For this, CI / CD tools such as Jenkins intervene, which can be quickly coupled to our workflow and make deployments with a simple click.

Last but not least, we must monitor the status of the system at all times. This will help us to discover faults as quickly as possible, as well as possibly their causes. With this purpose in mind we have several alternatives, some that even offer both free and paid versions (depending on the level of monitoring we want), but in Javascript backend environments one mainly stands out: PM2.

This tool will allow us to have a view at all times of the processes that are running, the times they have had to be restarted (in the case of a critical failure that causes the backend to stop, PM2 will be responsible for restarting it), various logs with errors or traces executed, and even a very interesting option: remote deployments from our local environment with a series of preconfigured options.

In any case, what is clear is that a backend, whether for a mobile application, a web or any other platform, is something that must be thought from the beginning with a good architecture, it must be designed to scale on different machines (they do not have to be physically located in the same location) and it has to be constantly monitored to solve the problems that sooner or later will appear.