5 ways to unblock yourself when the backend API isn't ready

Mock Server — Sat, 14 Mar 2026 12:32:46 +0000

You're mid-feature. You know exactly what the UI needs to do. The Figma file is open. You're ready.
And then you hit it — the backend endpoint doesn't exist yet.
You could wait. Or you could keep moving. Here are 5 ways developers actually handle this, from the quick-and-dirty to the more structured.

Hardcode the JSON directly in your component Yeah, it's ugly. But don't pretend you haven't done it.

const products = [
  { id: 1, name: "Wireless Headphones", price: 149.99, in_stock: true },
  { id: 2, name: "Mechanical Keyboard", price: 89.99, in_stock: false },
];

When to use it: You need to unblock yourself for the next 30 minutes and you'll throw this away by end of day.
When NOT to use it: When your teammate also needs the same data. When you need to test loading states. When you forget to remove it before pushing to main (we've all been there).

Run json-server locally json-server is a classic. You create a db.json file, run one command, and you have a full fake REST API running on localhost.

npm install -g json-server
json-server --watch db.json --port 3001

Your db.json:

{
  "products": [
    { "id": 1, "name": "Wireless Headphones", "price": 149.99 },
    { "id": 2, "name": "Mechanical Keyboard", "price": 89.99 }
  ]
}

Now GET /products and GET /products/1 both work out of the box.
When to use it: You want a persistent fake API that supports GET, POST, PUT, DELETE without writing any code.
When NOT to use it: When your teammate on a different machine needs the same endpoint. It runs locally — nobody else can hit it unless you do extra networking setup.

Mock Service Worker (MSW) MSW intercepts requests at the network level inside your browser using a service worker. Your app thinks it's hitting a real API. It isn't.

import { rest } from 'msw';
import { setupWorker } from 'msw';

const worker = setupWorker(
  rest.get('/api/products', (req, res, ctx) => {
    return res(
      ctx.json([
        { id: 1, name: 'Wireless Headphones', price: 149.99 }
      ])
    );
  })
);

worker.start();

When to use it: You want mocking baked into your codebase, colocated with your tests, and you're comfortable with some initial setup overhead.
When NOT to use it: You just need a URL to paste into Postman or share with a mobile dev. MSW lives inside your frontend — it's not a real URL anyone else can call.

Postman Mock Servers
If your team is already using Postman, their mock server feature is solid. You define a collection, add example responses to each request, and Postman gives you a real hosted URL.
The URL looks like https://abc123.mock.pstmn.io/products and anyone on your team can hit it.
When to use it: Your team already lives in Postman and you want mocks that match your existing API documentation.
When NOT to use it: You're working solo and don't want to context-switch into Postman just to create one quick mock. The setup flow is not fast.
An online mock tool — instant URL, no setup
Sometimes you just need a live URL in under a minute. No install, no config, no service worker, no Postman collection.
This is what tools like mockserver.in are built for. You describe your endpoint — or paste a schema — and it gives you a live URL immediately. The AI generation feature is genuinely useful here: type "return a list of 5 products with name, price, and stock status" and it writes the JSON for you.
What makes this approach different from the others:

The URL is publicly accessible — your mobile teammate can hit the same endpoint
Real-time traffic logs show every incoming request with headers and body, which is useful when you're not sure what your app is actually sending
You can simulate delay and intermittent failures — so you can test what your UI does when the API takes 3 seconds, or fails 20% of the time

When to use it: You need a shareable URL fast, you're testing across platforms (web + iOS + Android), or you want to test your error handling without touching the backend.
When NOT to use it: If your mocks need to live inside your codebase and run as part of your test suite, MSW is the better fit.

Which one should you use?
Honestly, it depends on the situation:

30-second fix, throw away later → hardcode it
Local development with full CRUD → json-server
Mocking inside your test suite → MSW
Team already on Postman → Postman mock servers
Need a shareable URL fast, cross-platform, with traffic logs → online mock tool

Most developers I've talked to end up using 2-3 of these depending on the context. The key is knowing which tool fits which situation instead of defaulting to the same approach every time.
What's your go-to when the backend isn't ready? Drop it in the comments.

Stop Waiting for the Backend — Mock Your APIs in 30 Seconds

Mock Server — Sun, 08 Mar 2026 02:50:30 +0000

Every frontend developer knows this feeling.
The backend isn't ready. You've got a Figma file, a deadline, and absolutely nothing to call. So you do one of three things:
Hardcode JSON directly into your component. Spin up json-server locally. Or just wait.
All three are painful in different ways.

The real problem with existing mock tools
The tools that exist today fall into two camps.
Too heavy. MSW is powerful but requires install, config, and service worker setup. Mockoon is great but it's a desktop app — your mock lives on your machine, nobody else can use it. MirageJS requires you to essentially rebuild your API layer inside your frontend.
Too simple. Most online mock tools give you a JSON endpoint but nothing else. No error simulation. No latency. No way to test what happens when your API is slow or broken.
Neither camp solves the actual problem: I need a working API URL my whole team can hit in under a minute, without setting anything up.

What frontend devs actually need
Think about the real workflow:

Designer hands off a screen
Frontend dev needs to build it
Backend endpoint doesn't exist yet
Frontend dev is blocked

What unblocks them isn't a perfectly architected mock system. It's a URL that returns the right shape of data, right now, that they can share with a teammate without any setup.
That's it.

The gap nobody was filling
When building my own projects I kept running into the same wall. I didn't want to install anything. I didn't want to write config files. I didn't want a mock that only lived on my laptop.
I also wanted to test the hard stuff — what does my UI do when the API takes 3 seconds to respond? What happens when it fails 30% of the time? These are real production scenarios that most mock tools completely ignore.
Intermittent failures especially. Every tool lets you set a mock to always return 500. But real APIs don't always fail — they fail sometimes. Testing retry logic means you need a mock that fails 1 in 3 requests. I couldn't find anything that did this simply.
So I built mockserver.in.

How it works
Three ways to create a mock:
Plain English — Type "return a list of 5 products with name, price, and image URL." It generates the JSON and gives you a live URL instantly.
JSON editor — Paste your own response body, set your status code, done.
Form — Fill in fields if you prefer structured input.
Every mock gets a shareable URL immediately. No account needed to get started.
Then you can layer on:

Fixed or random latency
Specific HTTP status codes
Intermittent failure rates — "fail 20% of requests"
Timeout simulation

Your frontend hits a real URL. Your mobile team hits the same URL. No one needs to run anything locally.

Who this is for

Frontend devs blocked by missing backend endpoints
Mobile devs who need a stable URL during development
Teams where backend and frontend work in parallel
Anyone who wants to test loading states, error handling, and retry logic without touching the backend

Try it
mockserver.in — free for 20 mocks, no credit card, no setup.
Describe your endpoint and get a URL in 30 seconds.

DEV Community: Mock Server

5 ways to unblock yourself when the backend API isn't ready

Stop Waiting for the Backend — Mock Your APIs in 30 Seconds