As a developer, I've run into the same problem countless times.
The UI is ready, but the backend isn't.
Maybe the backend team is still working on endpoints.
Maybe you're building a prototype.
Maybe you're validating an idea before investing time in a real API.
Or maybe you have a demo with a client, and you need to show something—even if it's just a mock.
Whatever the reason, development gets blocked surprisingly often by missing backend functionality.
The Usual Options
Most developers end up doing one of these:
Option 1: Hardcoded JSON
const users = [
{ id: 1, name: "John Doe" },
{ id: 2, name: "Jane Smith" }
];
This works for a few hours—or until the next sprint, when you need to rewrite the whole logic so it actually works with a real API.
Then you need:
- Pagination
- Filtering
- Search
- CRUD operations
- Authentication
- Relationships
And suddenly your fake backend becomes a project of its own.
Option 2: JSON Server
JSON Server is great, but eventually I found myself constantly editing JSON files, creating custom routes, and manually managing relationships between resources.
Option 3: Build the Backend First
This is often the "correct" solution.
But then again, you can't really demo a backend to a non-technical stakeholder and expect them to be amazed by the work being done.
It's also the slowest approach.
What I Actually Needed
I wanted something that could generate:
- GET endpoints
- POST endpoints
- PATCH endpoints
- DELETE endpoints
- Realistic fake data
- Pagination
- Filtering
- Relationships between resources
Without writing backend code.
Example
Let's say I'm building a blog application.
I create two resources:
Users
{
"name": "string",
"email": "email",
"avatar": "image"
}
Posts
{
"title": "string",
"content": "text",
"userId": "relation"
}
A few seconds later, I have:
GET /users
GET /users/:id
POST /users
PATCH /users/:id
DELETE /users/:id
GET /posts
GET /posts/:id
POST /posts
PATCH /posts/:id
DELETE /posts/:id
With realistic generated data.
Why This Matters
The biggest advantage isn't the fake data.
It's momentum.
Frontend development can continue immediately.
Designers can review flows.
Stakeholders can click through a working product.
Mobile apps can integrate against stable endpoints.
QA can start testing.
All before a production backend exists.
And perhaps most importantly: once the real backend is ready, there are usually very few changes needed.
Maybe a URL swap.
Maybe adding or removing a header.
That's it.
Loading states, error handling, authentication, pagination, filtering, and sorting have already been implemented and tested.
Additional Features That Became Surprisingly Useful
While building my own projects, I found myself needing:
- Authentication mocking
- Scenario-based responses
- Resource relationships
- Sorting and filtering
- OpenAPI imports for existing specifications
These features made the mock API behave much closer to a real production system.
The Tool I Ended Up Building
After repeatedly solving this problem across different projects, I decided to build my own solution: RestFaker.
The goal was simple:
Generate complete REST APIs in minutes so developers can keep building instead of waiting.
It automatically creates CRUD endpoints, generates realistic data, supports relationships between resources, and provides authentication and scenario testing features.
Final Thoughts
Frontend development shouldn't stop because a backend isn't ready.
Whether you're building an MVP, testing a new idea, creating demos, or working with a distributed team, having a realistic API available immediately can dramatically speed up development.
Do you use JSON Server, Mockoon, Postman Mocks, custom Express servers, or something else?
Top comments (0)