Stub APIs: A Tempting Shortcut with Hidden Costs
What to consider when providing stub APIs to the frontend teams. Why should you (not) do it in the first place.
tldr is at the end.
A couple of months ago, I had a long list of APIs that were to be provided to the mobile and web frontend teams. 9 people were dependent on me to continue their work (and would often stare from across the table) which was anticipated to take about a month. So, I chickened out and provided stub APIs so that they don’t sit idle. It was first for me, and I learned a lot during this process. Here’s a summary of my experience.
Stub APIs are temporary placeholders that provide mock data to frontend teams while backend development is still ongoing. While this technique might seem like a win-win at first glance, it comes with a hidden cost of increased complexity and potential technical debt
1. The URL Format
I was working with NestJS, and circular dependencies between modules are a bit complex. For example, if the "Employee Management" module relies on services from the "Leave Management" module, and there's an endpoint primarily associated with leave management, it might be tempting to place that endpoint in the Leave Management. However, if that endpoint later requires access to employee information, it could lead to complications.
Including references to "Employee Management" module in the "Leave Management" module would create a circular dependency between the two.
Moving the endpoint to a different URL would require changes for frontend teams.
This brings me to my next point.
2. Ask Frontend Teams to Store URL Endpoints in env File
All endpoints should be stored in the dotenv file so that the code does not get changed later on.
3. Use a folder to store all the stub responses and use them in your Service File
Even if a lot of endpoints are just returning a simple response like the following
{
“message”: “success”,
“status”: 200
}
Store them separately for each endpoint and require them in the service file (not your controller). This way, you will have a list of APIs that need to get implemented.
4. Conclusion
Don’t do it. I do not see much benefit of this technique. Plan ahead so that the backend and frontend are always in sync.
tldr;
Think thorough of all the services an endpoint might require later on and use the module that is a super set of these services.
The frontend teams should be coached to not use endpoints directly in their code. Instead they should use environment variables that hold them so that a change in the API URL does not mean a change in the React code.
Store all the stub responses in files in a folder dedicated to them. This will serve as a checklist of your technical debt.
Try as much as possible that the stubbing is not required.