How to build a backend for a mobile application
Building a high-quality API for a mobile or web application is not a trivial task. There are numerous factors affecting the decisions that need to be made long before the first line of code is written. Careful assessment of these factors at such an early stage will help ensure that proper decisions are made. That’s how a suitable, reliable, fast, and secure API is created in the most cost-efficient way, without any concessions in terms of the quality of delivered software.
Building backend from scratch
Usually, the first thing to consider is the complexity of the app. There are a multitude of tools available that may be sufficient on their own and serve as an API for apps of low complexity. However, in most cases, some custom code will have to be written as well. In such more complex apps, these tools only play a supporting role. For example, Firebase can handle the authentication aspects while Strapi can help take care of the content we present in our app. Other functionalities, deemed too complex for external tools, are provided by the API’s custom code.
Step 1: Gathering requirements
How can we know the level of complexity our app is going to reach? This is where software analysts shine! Their task is to approach the customer and gather all possible requirements for the product. When all is said and written down, it’s quite easy to see if this is enough to solely rely on existing solutions, or whether some (or a lot) of custom code is needed.
Step 2: Building mockups
What would an app be without a beautiful and appealing design, though? That’s where UI/UX designers come into play. They create app wireframes and mockups, which astonish everyone with neat icons and animations. Mockups also help analysts and the customer spot potential problems which may once again affect some of the business decisions. Sometimes it turns out that a potentially small application will need to be more complex or vice versa!
Step 3: Preparing API templates
Now is the time when software developers appear in the process. These new players, when facing the requirements, wireframes, and mockups, can also suggest some modifications to the customer. After all, two heads are better than one!
It’s essential to gather the team responsible for the entire backend development process (mobile developers, UX/UI designers, backend developers, frontend developers) to create an API template. If the whole squad is not available, there should be at least one person from the following fields: backend, website, and mobile.
Sometimes analysts and UX designers are also involved at this stage. Once the final touches to the requirements, UI and UX are made, it’s time to implement the API.
Building the API — what is important
While building any type of API, we have to make sure that it allows for conducting all the user interactions shown in the mockups. Without the proper implementation, we won’t be able e.g. to create an account, despite the presence of an account creation form in the app. Even with the best API, we need to implement the functionality on the backend.
Prepare API contract
Now is the time, when the development representatives from all parts of the upcoming software meet and work on the API contract. This usually involves a backend developer responsible for the API, and one for each of the client apps — a mobile app developer, a web developer, and potentially more! A well-prepared API contract covers everything described in the requirements and designs.
Teamwork is the key to success
It’s sometimes believed that even a single person, like the backend developer, could prepare such a contract. Speaking from experience, we can say that this is a bad idea. In most cases, it turns out that such a one-sided contract is deficient and forces client apps to behave in an inefficient way, especially regarding the number of network requests against the API. It is no different the other way around. That’s why API contracts should always be prepared by a team of developers.
Keep your teams on the same page
There is a big upside to having a proper contract written down. Namely, teams from different aspects of the app, like backend/mobile/web teams, can begin the development independently. It is desirable, of course, that all teams work at the same time, but in practice — it is rarely so. The contract ensures that the results of such independent work will… work!
Change management
The contract (as well as the API) should always be versioned. If destructive changes are made to the contract, a new version of the API must be created. Old API versions will then need to go through a support phase to allow client apps (like web or mobile to switch) to a newer version of the contract. The API should also expose an endpoint (or add an HTTP header) which will let the client app know if an update will need enforcing (this is, of course, for stubborn users who don’t update their apps even once in X months, so the API version in their app is no longer supported).
3 pillars of well-prepared API
Now that we are pretty sure that our API will provide all the required functionalities, it is time to think of its other, not a tiny bit less important aspects. Clients have three basic needs related to their mobile apps (as well as web apps) regardless of the business sector, app structure, etc.: speed, reliability, and security.
API speed
It would be a shame if mobile developers did their best to provide the smoothest user experience possible but what the user would see most often in their app would be the data loading indicators. That’s why it is crucial for an API to provide client apps with data in a blink of an eye.
It’s the role of backend developers and DevOps role to think of mechanisms that can speed up response times as much as possible. While 0.1 seconds is barely noticeable, some users will be thrown off by apps that take more than even 1 second to load/save data!
API reliability
While some mobile and web apps can operate to a degree without an active network connection, many actions will require communicating with the API. Surprisingly, the fastest API one could implement is a non-working one — the user would get an error response right away… But it’s not what we should be aiming at, so, while speed is an important factor, there is a more crucial one — API availability.
What’s worse than data being saved in a slow manner? Data that was lost upon saving! Backend developers and DevOps should always strive to keep the API up and running as close as possible to 100% of the time. Thanks to that, our customers won’t risk a heart attack seeing several pages of their newly written document disappear in some network void or an empty account balance after having transferred a billion dollars there.
API security
The last, but not least aspect is the security of our API. The user could be very understanding and forgive us for the app lacking a feature, being slow or inaccessible at times. They would definitely not want their transaction list, personal data, or credit card details shown to another user of the app.
That’s why API developers must pay the utmost attention to the proper handling of data ownership, user identity, roles, and permissions in the app. On the other hand, DevOps need to properly protect the inner workings of an API and its supporting services from any unauthorized access. This way they ensure that we run on the most up-to-date software possible. Also, backups are your friend, but that goes without saying, doesn’t it?
Daily API management
After we build an API once, it doesn’t mean that we can forget about it. We have to provide everyday care to make sure that it works properly and maintains the highest standards of quality and security. Here are some daily routines that we definitely should keep in mind and practice.
API monitoring
It’s always a good idea to take care of proper logging and monitoring of your API. Thanks to that, possible errors and API downtimes can be discovered and fixed immediately. Even with great monitoring, it is recommended to think ahead and proactively prevent downtimes. We can achieve it by spinning up several instances of the API server and redirecting traffic from a non-responsive instance to another one.
API cost optimization
If we know that the traffic to our API is high or changes a lot during the day, we could use cloud solutions. They should react immediately to changes in traffic and spin up additional server instances on the fly or shut them down when there are fewer users. It’s also a very cost-efficient solution in which you only pay for the actual traffic served. We don’t need to worry about the costs of keeping 10 instances up all day just for the most traffic-heavy 30 minutes.
API versioning
The app shouldn’t stop working simply because of changes applied to the API. The changes applied to the API must be consistent with the previous versions as well. If someone introduces a major change that will break the API convention, their responsibility is to build a new API version. Especially when there are changes to the URL address. After some time, the old APIs are deactivated. A good example of API versioning comes from Facebook which always accepts two previous versions of the app.
However, if some users are stubborn and haven’t updated the app, the backend must enable client applications to recognize when the current API version is no longer available for this application.
Best technology for backend
When choosing the best backend technology for our mobile app, we need to take into consideration three important factors: programming language compatibility, client requirements and needs, and budget limitations.
Programming language
Some people will try to convince you that the API should be written in Java, some will disagree and yell that C# is the only viable choice. Others will scream that it’s the 21st century and JavaScript is the only possible, trendy choice. You should rather listen to those who present you with valid technical arguments on why a certain technology should be selected. It is useful especially if they can suggest different languages for specific parts of the API. For example, if your API deals with image processing, Python offers a multitude of fantastic tools for doing just that.
Clients requirements
Specific technology isn’t very important for general-purpose APIs of medium complexity and you will be just fine with pretty much any popular choice. This is, of course, if the customer doesn’t have their own technical requirements. There may be other apps the client owns that were written in a given technology, a specific cloud platform, etc. The client may prefer to use their own server or ours. We can recommend them tested and reliable commercial solutions (e.g. Azure, AWS). The most important thing is meeting the client’s requirements but also allowing their app to reach its designed goal. These two might not go well together, so customers sometimes require our consulting. In such cases, the technology needs to be discussed and decided upon.
Budget limitation
The solutions offered to clients must fulfill their budgetary needs. And money issues can be varied. Our role is to make the app within the budget and sometimes renegotiate by showing benefits. For example, it is cheaper to create a server version of the backend. If the future scale of the project is uncertain, you can always offer a configuration allowing for redesigning the backend for more server instances. But sometimes clients must go with the cheaper versions and might need more improvements in the longer perspective (when they start making money).
Backend for mobile app — key takeaways
The backend must usually be built from scratch, but there are plenty of tools that can support this process and particular modules of our API. The process is not limited to implementing code — it also requires the stage of analysis, planning, and designing. It is essential to gather the entire development team to collect client requirements and settle upon a course of action.
The app must always be fast, reliable, and secure. What is more, the backend building process has to be in line with the client’s requirements and financial capabilities. We should also remember to keep the app’s end users happy. Sometimes the client needs our consulting to give their users what’s best for them. Providing a high level of customer experience and security should be our daily basis, so we need to constantly monitor and improve our API.
If you want to learn more about our mobile solutions, visit our website. You can also dive deeper into backend development with the following articles:
