Building UI against realistic fake responses before the backend exists.
Frontend work rarely gets to wait for the backend to be finished. The usual fix is to mock the API: intercept the request your frontend makes and return a fake response that's shaped exactly like the real one will eventually be. Done well, this lets frontend and backend work happen in parallel without either side blocking the other. Done poorly, it produces a UI that looks finished in the demo and falls apart the moment it touches the real API.
The most common mistake is mocking whatever's easiest to type rather than what the API will actually return. If the real endpoint returns null for a missing field, your mock should too — not an empty string, which behaves differently in a lot of rendering and comparison logic. Agree on the response shape (a JSON schema, an OpenAPI spec, or even just a shared example payload) with whoever owns the backend before building the mock, and treat that shape as the source of truth.
It's tempting to mock a single, clean 200-OK response and call it done. Real APIs also return 404s, 500s, validation errors with field-level messages, empty result sets, and paginated responses where the current page is the last one. If your mock never produces these, your UI's error states, loading states, and empty states will only ever get tested once — manually, right before shipping, when it's most expensive to fix.
A UI that only ever sees one hardcoded fake user will happily hide overflow bugs, truncation bugs, and layout breaks that only show up with a long name, a missing avatar, or a price with more digits than the design mockup assumed. Generate a batch of varied fake records — the JSON / CSV / SQL generator is built for exactly this — rather than reusing the same single example everywhere.
There are a few common places to intercept a request, each with a different tradeoff:
fetch/axios directly) — fast and simple for unit tests, but easier to drift from what a real request/response cycle looks like.A mock that was accurate on day one and never touched again is a slow-motion bug report waiting to happen — the real API evolves, the mock doesn't, and eventually the UI breaks in production while every test using the stale mock keeps passing. Whatever layer you choose, revisit your mocked payloads whenever the actual API contract changes, and treat mock drift as a real defect, not a formality.
Whichever approach you pick, you still need realistic-looking fake data to put inside the response. Use the structured data generator for JSON objects shaped like users, products, or orders, the names generator for realistic people, and the hash generator if your mock needs a plausible-looking token or checksum field.