Every frontend and mobile application connects with some API services.
At the very beginning of the project, the API endpoints are never available or they are not providing data in the correct amount or format to populate a frontend application.
Unless you are very lucky, it will be so for weeks or months, since the Backend Team is still developing them and struggling to search for some reliable data.
However, “Show Must Go On” and Frontend Team needs to start the development of the App or they will not be able to deliver anything.
So what can we do?
There are several approches and I’m going to describe what we do in Digit and what are the pros and contros.
Solution 1 – hardcode values
Hardcode values inside the code or patch a module to manage fake data.
This is a bad practice, we knows: it pollute the code and there are risks to forget fake data in production environment.
However, it’s very fast for complete a spike task or to create a POC for some new or complicated Layout Components.
Do this only at the very beginning of the development phase and add a refactor task to the backlog to remove the hardcoded values as soon as possible
Solution 2 – json file in folder /public/mocks
Put a json file in folder /public/mocks for each dataset you want to mock, and change the routing for the fetch to that file for the development environment
The Json file will be delivered by the same server that is running the React App.
However, this assumes that you have a configuration file with all the routes for each api endpoint and for each environment.
It’s a quick and dirty solution, but it’s very fast to implement.
Based on my experience, it can easily covers 90% of the use cases required during the development.
- very fast to implement and easy to configure
- it works only for web projects
- it requires a separate routing config file for all the routes.
Solution 3 – json-server
Create a separate NodeJs project, install json-server, and creates a fake API server.
It is very fast and easy to configure.
For most of the faked endpoints, it requires only to drop some json file in a folder and almost no coding.
Also, you’ll need to have a separate routes config file, as in solution 2.
- very easy to configure
- it works for both React and ReactNative projects
- total separation between mocked data and App.
- it requires a separate routing config file
Solution 4 – Mock Service Worker
It installs a service worker that intercept the fetch requests.
Then, the requests are routed to a separate module that returns the fake data, even if for each endpoint is requested to write a small piece of code.
It’s very powerful and easy to configure, but it support ReactNative application only for unit and integration tests, and not for development.
- Powerful and easy to manage
- It avoids a separate node project to run the server
- it can be used only for React web application
Solution 5 – Mirage JS
It creates a server object in the global window object.
The added object intercepts the fetch requests and it returns fake data.
It can be installed also on a ReactNative application.
You can find more details in their documentation.
- it avoids a separate node project to run the server
- the same pattern and code works for both a web and mobile application