What makes a good mobile backend? Let’s ask the frontend developers.

All mobile developers interact with some type of backend service in their everyday work. A sufficient mobile backend service is a key component of every successful mobile solution. Life is not all roses, however, and not every mobile backend service is created equal.

Every now and then, we hear our fellow mobile developers complaining about the behavior of a backend service. At the same time, our fellow backend developers protest that they have already done their best to satisfy the requirements.

That is why we started to investigate what actually makes a good backend and one (mobile) developers would be happy with. What kind of backend would make their job quick, easy and less frustrating?

Time to find out!

We drew up a little survey with questions, some of them multiple-choice and some open-ended. Ultimately, we were hoping to get results that would lead to better development efficiency and performance.

Our survey revealed that 90% of our mobile developers say communication with the backend team has always been a good experience. Working with the backend team to make meaningful products for end users is mostly a positive and rewarding experience for frontend developers.

But that’s not all they wrote. When asked about difficulties, this is what our developers also pointed out.

Problem 1: Documentation

Interestingly enough, the biggest problem developers reported with the backend didn’t concern technical issues or coding—it was documentation!

About 80% of the respondents said that a lack of quality in documentation is the one aspect of existing backend services that bothers them the most.

Without sufficient documentation, developers will have to ask more questions, resulting in delays to development. It is not uncommon for frontend developers to ask about the meaning of a specific service or the functioning of a certain API.

All of this adds extra cost and complexity to mobile development. Moreover, it also increases the demands on the backend team when creating the API service.

Most respondents complained about the lack of concrete examples in the documentation and that they did not know what to expect from the APIs. This creates complications for mobile developers when they have to define data models and design workflows based on these expectations. It wouldn’t be too much of an exaggeration to say that 90% of a successful service is good documentation.

Solution:

There are no shortcuts here. Documentation has to be clear, concise and readily available, and it needs to provide some practical examples as well.

Quality documentation isn’t written overnight. It is normally not good practice to do all the development work first and then go back and slap the documentation together.

We asked one of our fellow developer, Katri Vilonen, whether she had any tips on documentation. Seeing as she had coordinated the documentation aspect of her most recent project, we figured she would have some valuable insight.

“When starting the documentation process, you don’t have to aim for 100% completion. Integrate documentation with your development process,” she said.

That is to say, it is important to write the documentation while backend development is going on. Piece by piece, part by part, to build documentation that is as up-to-date as possible. It doesn’t need to be perfectly accurate at the beginning, but should still aim to be comprehensive and accurate enough without going into unnecessary detail.

Problem 2: Waiting for the backend team — or coordinating the development process

It seems that the backend teams of a number of companies were either too small or too busy. The lack of good documentation exacerbated this problem and further increased the demands on the backend team.

Nearly 90% of the mobile developers who took the survey said that the backend service was not ready at the start of mobile product development.

This issue is not always as serious as you might think, since the mobile team can still kick off development on the basis of requirements and documentation even if the backend service is not ready.

However, practical experience had shown that, without a fully developed backend service, the mobile development team constantly has to go back and tinker on the same features. This is next to inevitable because of constant changes in the API definition due to updated requirements, unexpected error cases or bugs discovered during the development process.

Solution:

The ideal solution for avoiding this pitfall is agile and robust project management, ensuring that backend service development is ready before the start of mobile development.

In the real world, however, we always need to factor in a variety of scenarios. If the project is going to be a long one, and mobile development needs to start right away, you should at least have a well-defined mock service in place with a complete API definition.

Such mock services must have a sufficient number of test datasets, and the on-going API development needs to include meaningful and feasible unit tests with content coverage.

Another common method is to reorganize the development process to prioritize components that do not depend on the backend.

Problem 3: Messy development practices

The third aspect we identified is that mobile developers appreciate good development practice. Our respondents identified a couple of “inadequate” development practices, such as a lack of error handling and insufficient development environments.

For example, error handling is more often than not considered to be in order as long as the correct 4xx and 5xx error codes are returned.

Similar situations crop up in the set-up of development environments/stages.

Many would consider the mere existence of such dev, test, production environments to be good enough, yet it is still not uncommon to hear mobile developers ask why the dev environment can’t reflect the production scenario. So this is another area that causes delays and frustration.

Solution:

“Good practice” is a general concept that can be given a variety of meanings. In our experience, there are a few methods that can make a big difference.

First, it is important to realize that even if deployment to one environment has been completed, it may not necessarily contain datasets representative of production, which leads to insufficient feature development and testing.

Furthermore, to achieve a user-friendly mobile solution, it is not enough to know whether or not something fails—you also need to know WHY it fails. It is the mobile development team’s responsibility to communicate to the end users what is going on when some actions in the application fail.

Providing context-based error messages is the job of the backend development team. Such error handling should give the mobile team the capability to inform end-users when things are not working as expected.

Problem 4: API design complexity

This was another thing that annoyed developers. Keeping it simple is often a good rule of thumb for API development. The complexity of the API contributes to the difficulties in mobile workflow development. We have often heard our backend coworkers ask what differences a web service API has from its mobile counterpart, for example.

It all comes down to the philosophical question of what constitutes “good API design”.

Teams with different responsibilities or developers from different backgrounds may have different, and even contradictory, answers to this question. For example, is it possible to use exactly the same set of APIs for both web and mobile applications? If not, what is the reason for their differences?

Solution:

There is no single right answer to these questions, but we can apply the golden rule for practically every API intended for a mobile application: Keep It Simple.

Decreasing the complexity of APIs can simplify the mobile application workflow significantly. Achieving this goal requires close cooperation between the mobile and backend teams.

As soon as the APIs have been defined, it makes sense to get the mobile developers and service designers involved to hear how the APIs could/would look like from their perspective.

To wrap things up…

The purpose of this article is to help avoid unnecessary difficulties and costs incurred from certain problems identified by our survey.

Nothing is ever perfect in the real world, but we can make the mobile developers much happier with just a few minor modifications to our backend service development practices!

Illustration: Joel Pöllänen