It was a Tuesday morning. New sprint. My task: build the product listing page.
Simple enough. Except the backend team told me the /products API would be "ready by end of week."
End of week came and went.
So I did what every frontend dev does in this situation.
When the real API finally came in - two weeks later - I spent another day ripping out all the hardcoded stuff.
There had to be a better way.
The Problem With Static Fake Data
Hardcoded mock data has a hidden cost most developers don't think about until it bites them:
1. It masks real UI bugs.
If your test user is always "John Doe" with a price of "$9.99", you'll never catch truncation issues, layout overflow, or currency formatting bugs. Real users have names like "Maria Martinez-Gonzalez" and prices like "$1,299.00".
2. It's not shareable.
Your local JSON file doesn't help your QA teammate on a different machine. Or your designer reviewing the feature. Or the Postman collection your backend dev wants to test against.
3. It couples test data to your codebase.
When requirements change, you're updating mock data in five places instead of one.
Enter Faker.js
Faker.js is a JavaScript library that generates realistic fake data on demand. Every call returns different data - run it 100 times, get 100 different users, all realistic, all structurally consistent.
This is great for local development and unit tests. But it still lives in your JavaScript code.
What if the API itself generated fresh data on every request?
The Idea That Changed How I Work
I started wondering: what if I could write a mock API endpoint with placeholders and the server would resolve them with Faker.js on every single request?
No code changes. Just configure once, get dynamic data forever.
That's exactly what I built.
SnapMock: Mock APIs With Built-In Faker Tags
SnapMock (https://snapmock.net) is the mock API platform I built to solve this problem. You create endpoints in a dashboard, define your response body with {{$tag}} placeholders, and every request gets fresh Faker-powered data.
Same URL. Different data every time. Zero backend code.
When your real API is ready, change one line - the URL - and remove the header. The rest of your frontend stays exactly the same.
What Else SnapMock Does
- Conditional rules - same endpoint, different response based on headers, query params, or body
- Sequential responses - return responses in order, great for pagination testing
- Chaos mode - randomly inject errors and latency to stress-test your frontend
- Stateful CRUD - GET/POST/PUT/DELETE with persistent state, zero backend code
- AI generation - describe in plain English, get a full endpoint config with Faker tags
- OpenAPI Import - paste a Swagger spec, import all endpoints at once
Try It
If you've ever sat around hardcoding fake JSON while waiting for a backend API - SnapMock is for you.
Free tier: 5 projects, 1,000 requests/day. No credit card. No install.
Try it at snapmock.net
P.S. - The backend API I was waiting for that Tuesday? It shipped three weeks late, returned slightly different field names than agreed, and broke two of my components anyway. Some things never change.
I hardcoded it.
Fine for day one. By day four, I was maintaining three different fake datasets across five components, none of them matching each other, all named some variation of mockData, fakeProducts, tempItems.
When the real API finally came in
Top comments (0)