This content originally appeared on DEV Community and was authored by Marco Coelho

Let’s say you are a backend developer, with some expertise in different systems. One day, your leader assigns you a new task; You have to develop and test a few REST endpoints for an upcoming mobile app. So far, so good. Since you have experience as backend developer, it is not that hard, alright?

You build and deploy the changes, and everything seems ok in the tests. No issues detected, the app is working fine, and so is the service running in the cloud to communicate with the app. But then, a few weird things start happening. A user complain about not being able to use the app. There was an error in the app first version, you already rolled out a hotfix, but the error seems to persist. Then, the system goes down due to a max quota rule. And you can’t debug what is going on, no matter how much you try.

It is in times like these we would like someone to share with us how to get around problems like those. Lucky for you, in my years as mobile software developer, I learned a few tips about backend development. So, I’m going to share here four things I learned when developing a backend service for a mobile app.

1) You don’t control when a mobile app updates

When developing a website, you will have control when to merge code and deploy. You choose when it’s time for the test version to go into the production environment. You may migrate the database first and deploy the backend, or choose the frontend instead. It all depends on how you planned your product version migration. And you have to plan the compatibility between your frontend and backend instances. Either that, or updating both at the same time while keeping the downtime restricted. So far, so good.

With mobile app development, you may release a new version anytime, but you can’t control when users will install it. The delay could be days or even years.

For instance, in a scenario where you need to perform an API migration (due to a framework update, for example). Do you consider the consequences of allowing both the old and new APIs at the same time? It could be a heavy load, or duplicated data. If that’s not possible, you must plan for when the older app loses access to the deprecated API. Will your HTTP server return a 404 Not Found? How will the older app versions handle that response? Will they crash, or will they retry? Or will you return a 200 OK with an empty body? Is the client built to handle a successful response that contains no data?

So yes, migrating a service on a mobile app is a lot more complicated than on your own website. One classic way is to follow the version standard for rest apis, by adding /v1 or /v2 and such. Remember to adjust different versions of the app to use different endpoints.

Another way is to check the app version, and redirect it to the proper url. Or to deny the usage of the older api by returning an error message. The former is a more friendly approach, but it may lead to a complex scenario of spaghetti api endpoints. The latter is a more forced approach, and it may not resonate well with your public. Especially if the app has a large audience who expects to be able to access the app at any time. It is a matter of choosing the most adequate answer to your problem.

2) Always authenticate an api call

Let’s say you are developing a stock broker website. You have to present information, and some of it will be specific for a user, and some will be public. For example, the history of operations by that user will be specific, while the real time value of the stock price will be open to everyone.

In this scenario, the architect may authenticate specific calls, leaving public calls unauthenticated. It is a sensible approach, as it helps avoid unnecessary overhead.

But when developing for a mobile application, this scenario changes. First of all, you no longer have a connection of 1 to 1, frontend to backend, instead now you have a connection of N to 1. When you create a service to enable hundred of thousands of simultaneous accesses, you could be vulnerable to a Denial of Service (DoS) attack. All it takes is to forget to authenticate the requests.

Before processing any request from a mobile app, you must identify and authorize it. It could be through an authentication token, an API key, or a client-side SSL certificate. And that rule applies even for open endpoints, like the one about stock prices, after all, you don’t want to face avoidable downtime in your service.

You should also consider measures like rate limiting to prevent spam, often done via a reverse proxy. If you don’t, you might get some leeches using your website service in their own website. Using a load balancer to distribute traffic across your servers is another suggestion.

3) Don’t expect an api request to represent real time action

When responding to a request from a browser, you may assume the time the request arrived is a decent approximation of the time the request was made. Of course, it makes sense after all. When a user navigates take actions on the website, it will send requests to the service.

With mobile apps, this assumption is often false. A user might perform an action while offline (e.g., in airplane mode or outside roaming coverage). The app may store that action in the device and sync it with your server once connectivity returns, hours or days later. As such, the server’s request timestamp does not reliably represent the instant when the action occurred.

If recording the event time is crucial, the mobile client should timestamp the action when it happens and include that timestamp in the data. The service must be ready to accept it.

4) Make sure you add product and OS information to your calls

Imagine the following scenario. You go to work at morning, and your first ticket to check out is about an user not being able to save or update a record. While checking the backlogs for the service, you see this problem seems to repeat, but only with this user. So, what is the first suspect in this erratic behavior scenario that affects only one user? The browser type and version, of course.

If the client’s browser type and version does not explain the issue, the search expands. Other factors, like the OS version, network routing, or authentication may be why.

The same line of thought applies to a service providing an endpoint for a mobile app. Whenever a mobile client makes a request, it is very important to provide its OS version and manufacturer. Those details may be crucial to debug the issue at hand. Some issues only do happen on a specific version of OS or vendor. Send the information in the request header or body, depending on your strategy. Ensure your service logs this information for a reasonable time, especially alongside any errors. So the more you know about the error when it happens the first time, the easier will be when debugging it.

Final Considerations

Creating a backend service for a mobile app is no different from any other service. Yet, the mobile app is a consumer whose update cycle and environment are outside your control. Because of those restrictions, make sure to create a proper plan for updates and changes. Knowing the particularities of Android and iOS will help you when building and maintaing a reliable service for them.

Doing so should not be a daunting task, as the modern state of both Android and iOS are particularly similar. Given how hybrid technologies are popular today, most solutions will work for both. Still, having a background in native development, knowing each OS details will help you to design your service. Especially if you need to ramp up security and performance. And if you enjoyed this article, follow me on my website and social media pages for more articles.