Backend Mocking — An overview

You have your project environment set up, you started to build the first set of features — but then, suddenly, you are blocked by a nonexistent backend. As a web or mobile frontend developer, it’s likely that you have encountered this situation at least once.

One way out of this misery is using backend mocks. In this article, I want to give a short overview of motivations for building backend mocks, what alternatives you have for building those and what you need to consider when choosing the correct strategy for your project.

Why mock backend functionality?

In my current project, we are building an iOS and an Android app for a brand new product. At the time of the kickoff, our client just started working on the whole project’s setup, so there was - of course - no backend implemented yet.

That is why we sat down with both, the frontend and backend development teams right at the start of the project. After a few iterations, we agreed on the API’s design, so the backend team could start implementing it.

Since that point in time, the frontend team already was ahead of the backend team by quite a bit, we decided to build a mock backend ourselves. This would enable the frontend teams to continue working on features and the QA team to test the frontends without being blocked by missing backend services.

In general, i would recomment to mock backend functionality when you face a combination of the following circumstances:

• The frontend team is ahead in feature development
• Further development can’t wait for the backend to be ready
• Your QA team relies on actual working features for testing
• The backend team building a mock would cost even more time

What you need to consider

Make sure you have a well-aligned API before starting to mock since every change means that the mock needs to be updated.

As we already had agreed on what the API would look like and on how the mobile clients would use it, we could take the next step: Find out which requirements we have for the mock.

If you want to build a mock for your team, you have a whole lot of options, but not all of them will meet your requirements. When gathering your requirements, you should consider the following topics:

• Availability: Do you need the mock outside of your development environment?
• Functionality: Do you need input validation?
• Flexibility: Do you need the mock to be easy to update?
• Effort: How much time do you want to invest?

Having those four topics in mind, we sat down for a short meeting and collected the following requirements for our project:

1. Both iOS and Android need the same data and behavior
2. The mock needs to be accessible via mobile internet for testing
3. The mock needs to be able to validate request headers + body
4. It must be easy to modify data for demo and testing purposes
5. We need the mock to be ready within a couple of hours

Your Options

If you google for backend mocks, you will find a ton of options. There are simple and straightforward options, more flexible ones, paid services and of course, you can build your own custom solution. Depending on your specific requirements you might end up choosing a different approach on different projects.

Some of the most prominent options are:

• Mocking in frontend code
• Serving data using plain JSON files (local or online)
• Running a local mock server on developer machines
• Using Paid services
• Hosting your own code in the cloud

Options vs. Requirements

Let’s now have a second look at the topics from above in combination with our requirements and see what their implications on our options are.

Availability: Local or cloud?

Hosting a local mock server on your developer machine can be a quick win, but usually, it’s not the best choice for bigger teams. Especially if your QA team also needs access to the same mock, you’ll either have to mock in your code (with double the effort if you build for two platforms) or host your mock somewhere in the cloud. In our case, we even needed the mock to be available on the go, so we decided to go with the cloud path.

Functionality: Basic or complex?

If you only need to support simple GET requests, using some JSON files in the code or on AWS S3 might do the trick for you, but what if you need input validation or even want to build in some test scenarios for your QA people? Well, then you might be better off with hosting a mock-server that can execute at least some logic. Since we wanted our mock to be as close to the final API as possible, we went with an option that would allow us to validate both HTTP headers and bodies.

Flexibility: Static or updateable?

In case you’ve already decided to host a mock either locally on your machine or in the cloud, you still have choices. API documentation in Swagger allows you to generate a mock server using swagger-codegen. But, if you need to add custom data to your mock and be able to update the interface, you might end up replacing your custom data with the newly generated code. In our project we reached this point, so we decided to upgrade to a completely custom NodeJS-based mock.

Effort: How much time do you have?

Even if you would like to build the most flexible and powerful mock, the resources you have at hand to do so are most likely limited. If you need a somewhat advanced mock but are not in the position to build a custom one, a paid cloud solution might be worth a look.

Conclusion

Building a mock backend for our mobile frontends was the one best thing we could have done at the very beginning of the project. It unblocked the frontend teams immediately, allowing them to build a large part of the app before the first backend services were online.

However, choosing the right approach for mocking requires some thinking and careful consideration of four important factors: Availability, Functionality, Flexibility, and Effort.

After you have sat down and clarified your requirements, make sure your API design is final because otherwise, every change will require an update of your mock.