I'm getting frustrated with my frontend workflow because backend API schemas are often delayed, incomplete, or changed during the sprint. I currently hardcode fake JSON in components or spin up a quick local json-server, but that becomes messy when I need multiple routes, artificial delays, and error states such as 500 responses or slow networks. Tools like MSW and Postman sometimes feel like too much setup when I only need a temporary endpoint for a few days. How do you keep frontend work moving without waiting on backend or polluting the codebase with throwaway data?
4 Answers
MSW is worth learning for this. Once the initial setup is done, one handlers file can intercept fetch or Axios calls and simulate normal responses, delays, and 500s without running a separate server or changing component code. For schema changes, agree on an OpenAPI contract early and generate frontend types from it so incompatible changes fail during development.
The most important part is agreeing on the API contract before implementation. Once the request and response shapes are written down, the frontend can build against mock responses while the backend fills in the real behavior. A tool such as Prism can turn an API specification into a temporary mock server, although a lightweight local route handler works too.
Keep the mocks at the network boundary instead of putting fake data directly in components. A small handler layer with shared fixtures and switches for latency, empty states, and server errors is usually enough. Then you replace the handlers with the real API without rewriting the UI.
If you control the backend, add a temporary mock implementation at the controller or endpoint level. The frontend gets to integrate with the actual URL and response format, while the backend team can replace the implementation later. For UI-only work, Storybook fixtures are also useful because they let people review loading, empty, success, and error states without needing a live API.
That works especially well for client projects where waiting for another team isn’t realistic. I usually cover the important UI states with fixtures first, then switch the same components over to the real endpoint.
That setup friction is what has been slowing me down, but having reusable handlers and generated types sounds more sustainable than rebuilding a temporary server every time.