How I Stopped Waiting for the Backend to Be Ready

Nimmly — Thu, 11 Jun 2026 07:59:37 +0000

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?

If You Wanna Try It Yourself

https://restfaker.dev

DEV Community: Nimmly