API Mock Data Generation for Frontend Development
Frontend developers often need to work before the backend API is ready. Mock data generators create realistic API responses that match the expected schema, enabling parallel development.
Key Takeaways
- Waiting for the backend to be complete before starting frontend work wastes time.
- The simplest approach: create JSON files that mirror expected API responses.
- Good mock servers simulate failure modes:
- Cons: Setup overhead, must maintain mocks.
- Pros: Always in sync with API contract.
Why Mock APIs
Waiting for the backend to be complete before starting frontend work wastes time. Mock APIs decouple the two teams, allowing parallel development with agreed-upon contracts (schemas).
Approaches
1. Static JSON Files
The simplest approach: create JSON files that mirror expected API responses. Serve them with a static file server or import directly in code.
Pros: Zero setup, version-controlled. Cons: No dynamic behavior, stale quickly.
2. Mock Server
Tools like MSW (Mock Service Worker), JSON Server, or Prism intercept API requests and return mock responses. MSW runs in the browser's service worker β no separate server process needed.
Pros: Realistic network behavior, error simulation. Cons: Setup overhead, must maintain mocks.
3. Schema-Driven Generation
Define your API with OpenAPI (Swagger) and use tools that auto-generate mock data from the schema. Libraries like Faker.js can populate schema-defined types with realistic values.
Pros: Always in sync with API contract. Cons: Requires upfront schema definition.
Mock Data Quality
| Aspect | Bad Mock | Good Mock |
|---|---|---|
| Names | 'Test User 1' | 'Alejandra Moreno' |
| Dates | '2020-01-01' everywhere | Varied realistic dates |
| IDs | 1, 2, 3 | UUIDs or realistic ID formats |
| Lists | Always 3 items | Varying lengths (0, 1, 5, 20) |
| Errors | Never tested | Include 404, 500, timeout scenarios |
Error and Edge Case Simulation
Good mock servers simulate failure modes:
- Slow responses (add artificial latency)
- Empty results (no data state)
- Paginated results with varying page sizes
- Authentication errors (401, 403)
- Server errors (500, 503)
- Network timeout
Testing against these scenarios in development catches error handling bugs before they reach production.