DEV Community: Kudasov Dmitriy

Why URL-Only API Mocks Break Down in Real Frontend Work

Kudasov Dmitriy — Tue, 02 Jun 2026 19:43:34 +0000

Frontend mocks often start with a URL.

That makes sense.

You see a request like this:

GET /api/orders

Then you create a mock for /api/orders, return a response, reload the page, and check the UI.

For simple cases, that works well.

But real frontend work gets messy quickly, because the URL is often not the full state.

One endpoint can mean many states

A single endpoint can represent many different product situations.

For example:

GET /api/orders?status=failed&page=1
GET /api/orders?status=paid&page=1
GET /api/orders?status=pending&page=3

All of these may hit the same path:

/api/orders

But the UI states can be completely different.

One response may show a full list.
One may show an empty state.
One may show a warning.
One may trigger a pagination bug.
One may expose a permissions issue.

The endpoint path is the same, but the frontend state is not.

That is where URL-only mocks start to feel too thin.

Request bodies make this even harder

The problem becomes more visible with POST requests.

A lot of modern APIs reuse one endpoint and put the important state inside the request body:

POST /api/integration/list

{
  "documentType": "invoice",
  "accountId": "acme",
  "includeArchived": false,
  "page": 1
}

Change one field and the response may represent a different UI state.

Maybe documentType changes the schema.
Maybe accountId changes permissions.
Maybe includeArchived changes whether the list is empty.
Maybe page exposes a pagination edge case.

If a mock only matches the URL, it cannot distinguish these states.

It can say:

Mock /api/integration/list.

But it cannot say:

Mock /api/integration/list only when documentType is invoice and accountId is acme.

That difference matters when you are trying to test a specific frontend behavior.

Staging data does not always help

One common answer is: "Use staging."

Staging is useful. It catches integration problems and gives teams a shared environment.

But staging is not always good at giving you the exact state you need at the exact time you need it.

Maybe staging has data, but you need an empty list.

Maybe the backend is healthy, but you need to test a 500.

Maybe the response is fast, but you need to inspect a loading state.

Maybe you need a specific permission failure, but nobody wants to mutate a test account for one UI check.

Maybe a QA edge case disappears because someone else changed shared test data.

None of this means staging is bad.

It means staging is not always the fastest tool for small frontend state work.

Mock servers are powerful, but sometimes heavy

Mock servers are also useful.

Tools like MSW, Mockoon, WireMock, Postman mocks, Playwright route interception, and Cypress intercepts all have valid places in the stack.

They are especially useful for:

repeatable test suites
shared API contracts
backend-independent development
team-wide fake environments
CI workflows
larger mocking strategies

But sometimes the task is smaller.

You are not trying to design an entire fake backend.

You are staring at one screen and thinking:

I need this one browser request to return this one response so I can see this one UI state.

For that kind of work, a full mock-server setup can be more structure than the problem needs.

The useful mock starts from the real request

This is the product direction behind Ruse.

Ruse is a Chrome extension for local-first API mocking inside the browser.

The current public version, Ruse v0.2.0, is already live in the Chrome Web Store.

Today, the workflow is:

Open the app you are testing.
Open Ruse on the working tab.
Capture a real browser request.
Create a local mock rule.
Organize rules into local collections.
Reload the UI and inspect the state.

No account is required for the current local workflow.

The next quality pass, v0.3.0, is focused on making HTTP rule creation more request-aware.

The goal is not to build a huge platform immediately.

The goal is to make the core browser loop stronger:

capture request -> inspect request -> edit response -> save local mock -> reload UI

Matching the state, not only the path

A better local mock should understand more than the endpoint path.

For many frontend cases, you want to start from the request that actually happened in the browser and decide which parts should matter.

For example, if the captured request body is:

{
  "documentType": "invoice",
  "accountId": "acme",
  "includeArchived": false,
  "page": 1,
  "clientRequestId": "temporary-random-value"
}

You may want the mock to care about:

{
  "documentType": "invoice",
  "accountId": "acme"
}

But not care about:

{
  "clientRequestId": "temporary-random-value"
}

That is the difference between mocking an endpoint and mocking a state.

The request fields that define the UI state should matter.

The noisy fields should not.

This is not about replacing every testing tool

I do not think browser-level local mocks replace proper tests.

They do not replace contract testing.

They do not replace backend integration testing.

They do not replace staging.

They do not replace a serious mock-server setup when a team needs one.

The value is narrower:

When you need to reproduce one frontend API state quickly, inside Chrome, starting from real browser traffic, local browser-level mocking can be the fastest path.

That is the lane Ruse is being built for.

Practical examples

Here are the kinds of states where URL-only mocks can be too limited:

Same endpoint, different filters
Same endpoint, different account
Same endpoint, different user role
Same endpoint, different document type
Same endpoint, different request body
Same endpoint, different pagination state
Same endpoint, different feature flag
Same endpoint, different permission result

The frontend does not care that the path is the same.

The frontend cares what state the response represents.

Where Ruse is going next

Ruse v0.2.0 is live now.

The next development focus is v0.3.0, which is planned as a quality pass around HTTP rule creation:

Builder-first selected request workflow
request parameter/body subset matching
cleaner response body editing
response status/type/delay controls
response header cleanup
clearer mocked logs
a tighter working-tab permission model, once final QA confirms it

I am deliberately keeping this scoped.

No accounts in v0.3.0.

No billing.

No teams.

No cloud sync.

No dedicated GraphQL or WebSocket editor yet.

The point is to make the core HTTP workflow feel right before expanding the product surface area.

Try the current workflow

If you build frontend against APIs that are hard to control on demand, try Ruse v0.2.0 on one real screen.

Pick one API state that usually slows you down:

empty list
500
slow response
malformed JSON
permission denied
filtered result
pagination edge case

Then see whether controlling that state locally in Chrome helps your UI loop move faster.

Website: https://ruse.dev

Chrome Web Store: https://chromewebstore.google.com/detail/becjmbgcgfddoahaoigeeogohpbcmgic?utm_source=item-share-cb

How to Test Frontend Error States Without Breaking Your Backend

Kudasov Dmitriy — Fri, 29 May 2026 13:30:00 +0000

Frontend teams are usually pretty good at testing the happy path.

The API returns 200. The response shape is correct. The list has data. The network is fast enough. The user sees the page we designed.

Great.

But products do not live only in the happy path.

They live in all the awkward states around it:

the endpoint returns 500
the list is empty
the request is slow
the response is malformed
the token expired
the user has no permissions
staging data changed again
the backend endpoint is not ready yet

These states are often where the UI becomes the most important. They are also the states that are hardest to reproduce on demand.

The problem with relying on staging

A lot of teams treat staging as the place where frontend edge cases should be tested.

In theory, that makes sense.

In practice, staging is rarely in the exact state you need.

Maybe you need an empty list, but staging has 400 items.

Maybe you need the API to return a 500, but the backend is currently healthy.

Maybe you need a slow response to test loading behavior, but the request is too fast.

Maybe you need a specific permission error, but nobody wants to mutate test data or add a temporary backend flag just so you can check one UI state.

So the frontend workaround begins.

Common workarounds

There are a few common ways to deal with this.

1. Mock servers

Mock servers are powerful. They are great when you need shared contracts, stable fake environments, or a full backend replacement during development.

But they can also be heavy when the task is small.

Sometimes you do not need a full mock environment. You just need this one request to return an empty array for ten minutes while you fix a UI.

Setting up a mock server for that can feel like too much ceremony.

2. Local fixtures

Local fixtures are fast and simple.

You create a JSON file, import it somewhere, and render the UI against that data.

This works well for isolated components. But it gets harder when the behavior depends on the actual network flow of the app: auth, routing, loading states, retries, request timing, headers, or runtime conditions.

Fixtures can also drift from real API responses over time.

3. Backend flags or test endpoints

Sometimes the backend team can add a flag, seed special data, or expose a test endpoint.

That can be useful, especially in mature teams.

But it also creates coordination overhead. The frontend developer has to ask for the state, wait for it, and hope it still exists when QA or design tries to reproduce the same thing later.

4. Browser hacks

We have all done some version of this.

Add a temporary throw. Edit code in DevTools. Comment out a fetch call. Hardcode a response. Change a local branch just to force an error state.

It works, but it is fragile. It is also easy to forget, hard to share, and not something you want to rely on for repeatable testing.

A lighter workflow: override the response locally

For many frontend tasks, the ideal workflow is smaller:

Open the app.
See the real request the app is making.
Choose the request you want to control.
Return the response you need.
Reload and test the UI.

No backend change. No proxy setup. No full mock server. No app code changes.

Just one local override for one real browser request.

That is the workflow I have been thinking about while building Ruse.

Example states worth testing

Here are a few states I think every production UI should be easy to test.

Empty list

{
  "items": []
}

Does the UI show a thoughtful empty state? Is the CTA correct? Does the layout collapse awkwardly? Does pagination disappear?

Server error

{
  "error": "Internal server error"
}

Does the page recover? Can the user retry? Is the message useful? Does the app accidentally show a blank screen?

Slow response

A slow API often reveals problems that fast local development hides.

Do loading indicators appear? Do buttons stay disabled? Does the page jump when data arrives? Can the user trigger duplicate actions?

Malformed response

{
  "items": null
}

This is where defensive UI code gets tested.

Does the app fail gracefully, or does one unexpected value take down the entire screen?

Permission error

{
  "error": "You do not have access to this resource"
}

Permission states are product states too. They need design, copy, and behavior.

Why browser-level mocking is useful

Mocking at the browser level is interesting because it starts from what your app is actually doing.

You are not inventing a request from memory. You are not manually recreating the URL, method, and response shape from scratch. You are looking at real traffic and deciding: "for this request, return this instead."

That makes the loop feel more natural for frontend work.

It is especially useful when you are:

building UI before the backend is complete
testing error states
preparing stable demos
reproducing QA bugs
checking loading behavior
designing empty states
working against flaky staging data

Where Ruse fits

I am building Ruse as a Chrome extension for this workflow.

The idea is simple:

inspect browser requests
create local mock rules
return custom responses
test the UI state you need
keep everything local in the browser

Ruse is intentionally small and local-first. It is not trying to be a full API platform. It is focused on making the first useful mock fast.

Ruse v0.2.0 is now published in the Chrome Web Store, with a cleaner working-tab flow and local collections for organizing mock rules.

If this workflow sounds useful, install Ruse and send feedback from a real frontend workflow:

https://ruse.dev

Final thought

Frontend edge cases should not require a backend meeting.

Sometimes you need a full mock server. Sometimes you need contract testing. Sometimes you need proper seeded environments.

But sometimes you just need one request to return one different response so you can finish the UI in front of you.

That small loop is worth making better.

Ruse v0.2.0 Is Live: Local Collections and a Cleaner Working-Tab Flow

Kudasov Dmitriy — Wed, 27 May 2026 13:30:00 +0000

Ruse v0.2.0 is live in the Chrome Web Store.

This is not a huge platform release, and that is intentional. The goal of this version is simple: make the first real browser API mocking workflow feel less clumsy.

When you are building frontend UI, the problem is often not that you need an entire fake backend. Sometimes the problem is much smaller:

the API returns a happy path, but you need an error state
staging has data, but you need an empty state
the backend is healthy, but you need to test a 500
the request is fast, but you need to inspect a loading state
the endpoint exists, but the exact QA state keeps disappearing

Ruse is being built for that kind of moment: one real browser request, one local mock rule, one UI state you need to control.

What changed in v0.2.0

1. Ruse now starts from your working tab
The old tab selector flow is gone.

In v0.2.0, Ruse attaches to the current tab when the side panel opens. That sounds small, but it matters because the tool should follow the workflow you already have:

Open the app you are testing.
Open the Ruse side panel.
Capture a real request.
Create a local mock rule.
Reload and inspect the UI.

There is less setup before the first useful action.

2. Local collections for mock rules
Ruse v0.2.0 adds local collections so rules do not become one long, messy list. The current limits are intentionally small:

up to 20 local rules
up to 3 local collections
each rule can belong to one collection or stay ungrouped

That is enough structure for the current product without pretending Ruse is already a full team platform.

Example collections:

Checkout errors
Dashboard empty states
Slow API demos

3. Assign rules while creating or editing
Rules can now be assigned to a collection in the create and edit flows. This is useful when you are already thinking in scenarios:

"this rule belongs to the billing screen"
"this one is for a demo"
"these three are all empty-state cases"

The rule organization happens close to the moment where the rule is created, instead of becoming cleanup work later.

4. Drag-and-drop between collections
You can move rules between collections and ungrouped rules with drag and drop.

This is a small interaction detail, but it keeps the local workflow fast. Ruse should feel like a tool you can use while thinking about the product state, not like another admin panel.

5. Rename and delete collections safely
Collections can be renamed or deleted. Deleting a collection does not delete its rules. The rules move back to ungrouped. That behavior is deliberate. In a local testing tool, destructive organization actions should not quietly destroy the mock rules you made while debugging.

What v0.2.0 is not

This release does not add cloud sync, auth, team workspaces, billing, shared collections, or rule version history. Those are bigger product directions, but they are not the current promise. The current promise is narrower:

Make browser-level local API mocks easier for frontend developers and QA engineers.

That means the product should stay honest about what it does today.

Why this release matters

The first version proved the basic idea: Ruse can help turn browser requests into local mock rules.

v0.2.0 is about making that idea easier to use once you have more than one rule.

One rule is a demo.
Several rules are a workflow.
Once you start testing a real screen, you quickly need more than one state:

normal data
empty data
loading
server error
malformed response
permission error

Collections make that local workflow easier to keep in your head.

The working-tab behavior also matters because a browser extension should feel attached to the thing you are testing. If you are already in the right tab, Ruse should not ask you to solve a tab-selection puzzle before you can work.

A practical v0.2.0 workflow

Try this with a real frontend screen:

Open the page you are building or testing.
Open Ruse on that tab.
Capture the request for the data you want to control.
Create a local mock rule.
Make one response return an empty list.
Make another response return an error.
Put both rules into a collection named after the screen or scenario.
Reload the UI and test the states intentionally.

This is where Ruse should be useful: when you need a fast local testing loop without asking the backend, staging, or a mock server to change.

Where Ruse goes next

The next active development focus is v0.3.0.

The current plan is another quality pass around HTTP rule creation:

safer create-from-log drafts
better response body editing
JSON validation and formatting
response header editing
noisy header sanitization
investigation into permission reduction where it is safe

The direction is still the same: make the local browser mocking loop feel faster, safer, and more predictable.

Try it
Ruse v0.2.0 is available now:

https://ruse.dev

If you try it, the most useful feedback is specific:

Was the working-tab flow obvious?
Did collections help organize real testing work?
Where did creating a mock rule still feel slow?
Which API state do you still find painful to reproduce?
That feedback is exactly what should shape the next release.

Ruse Is Live: Mock API Responses in Chrome Without a Mock Server

Kudasov Dmitriy — Mon, 25 May 2026 13:00:00 +0000

Ruse is now live in the Chrome Web Store.

It is a Chrome extension for frontend developers and QA engineers who need to test API states that are hard to reproduce on demand.
The first version is intentionally small:

capture a real browser request
turn it into a local mock rule
change the response
reload your app
test the UI state you actually need

No mock server.

No proxy setup.

No app-code changes.

The problem

Frontend development often gets blocked by API states that are technically possible, but practically annoying to reproduce.

Maybe the backend endpoint is not ready yet.
Maybe staging has the wrong data.
Maybe you need the API to return a 500, but the backend is healthy.
Maybe you need an empty list, but the shared environment has 400 records.
Maybe QA found a bug in a permission state that nobody can reproduce anymore.

These situations are not rare edge cases. They are normal frontend work. The annoying part is that the usual workarounds can be heavier than the task itself.

Common workarounds

Mock servers
Mock servers are powerful. They are useful when a team needs a shared fake backend, stable contracts, or a full development environment. But sometimes you do not need a whole mock environment. Sometimes you just need one request to return one specific response for ten minutes.

Local fixtures
Fixtures are fast for isolated components, but they do not always match the real network flow of the app.

Authentication, request timing, retries, headers, routing, and runtime conditions can all matter.

Backend flags or special test data
This can work in mature teams, but it creates coordination overhead. You have to ask someone to create the state, wait for it, and hope it still exists when QA or design tries to reproduce the same screen.

Temporary code hacks
We have all done this.

Add a temporary throw. Hardcode a response. Comment out a fetch call. Edit something in DevTools. Change a local branch just to force the UI into one state.

It works, but it is fragile and easy to forget.

What Ruse does

Ruse takes a smaller approach. Instead of starting with a mock server or a config file, it starts with the request your app is already making in the browser.

The workflow is:

Open your app in Chrome.
Open Ruse.
See browser requests in the request log.
Pick the request you want to control.
Create a local mock rule.
Change the response body, status, headers, or delay.
Reload and test the UI state.

That is the core loop.
Real request -> local mock -> controlled UI state.

What you can use it for

Ruse is useful when you need to test states like:

empty lists
500 errors
404 states
slow responses
malformed JSON
permission errors
expired sessions
missing backend endpoints
stable demo data

The point is not to replace every other API mocking tool. The point is to make one browser-level override fast enough that you actually use it during normal frontend work.

What v0.1.0 is not
The first version is not trying to be a full API platform.

It is not an API client.
It is not a complete mock server replacement.
It is not a team collaboration suite yet.

That is intentional. The first version focuses on one question:

Can a frontend developer control a real browser request locally, quickly enough to test the UI state they need right now?

If that loop is useful, the product can grow from there.

Why local-first matters

For v0.1.0, Ruse is local-first. That means the first useful version should not require a complex account setup just to mock one API response in your browser.

The goal is to keep the initial workflow lightweight:

install extension
open app
capture request
create rule
test state

Future versions can add better organization, sync, teams, and more advanced workflows. But the first version should earn trust by being simple.

Who should try it

Ruse is probably useful if you are:

a frontend developer building against incomplete APIs
a QA engineer testing edge cases
a full-stack developer building frontend and backend in parallel
a developer preparing a demo that needs stable data
someone who keeps hardcoding API responses just to test UI states

It is especially useful if you have ever said:

I just need this one request to return something different for a few minutes.

What feedback would help most

The best feedback right now is specific and practical.

For example:

Which request did you try to mock?
Did the request log make sense?
Was the rule editor clear?
Did a permission feel scary or unclear?
Did a mock fail where you expected it to work?
Which API state did you want but could not create easily?
What felt slower than it should?

That kind of feedback is more useful than generic praise.

What comes next

The next version is already in motion.

The focus is on:

lighter permissions
better rule organization
cleaner local workflows
faster request-log-to-rule flow

The product is live now, but it is still early enough that real user feedback can shape the next release.

Try it

If you build frontend against unstable APIs, try Ruse and send feedback.

Website: https://ruse.dev

Chrome Web Store: use the install link on the Ruse website after the production landing update is live.

If you test it on a real frontend workflow, I would love to hear what breaks, what feels unclear, and what should be easier.

How to Test Frontend Error States Without Breaking Your Backend

Kudasov Dmitriy — Thu, 21 May 2026 16:32:31 +0000

Frontend teams are usually pretty good at testing the happy path. The API returns 200. The response shape is correct. The list has data. The network is fast enough. The user sees the page we designed.

Great.

But products do not live only in the happy path.
They live in all the awkward states around it:

the endpoint returns 500
the list is empty
the request is slow
the response is malformed
the token expired
the user has no permissions
staging data changed again
the backend endpoint is not ready yet

These states are often where the UI becomes the most important. They are also the states that are hardest to reproduce on demand.

The problem with relying on staging

A lot of teams treat staging as the place where frontend edge cases should be tested. In theory, that makes sense. In practice, staging is rarely in the exact state you need.

Maybe you need an empty list, but staging has 400 items.
Maybe you need the API to return a 500, but the backend is currently healthy.
Maybe you need a slow response to test loading behavior, but the request is too fast.
Maybe you need a specific permission error, but nobody wants to mutate test data or add a temporary backend flag just so you can check one UI state.

So the frontend workaround begins.

Common workarounds

There are a few common ways to deal with this.

1. Mock servers
Mock servers are powerful. They are great when you need shared contracts, stable fake environments, or a full backend replacement during development. But they can also be heavy when the task is small.

Sometimes you do not need a full mock environment. You just need this one request to return an empty array for ten minutes while you fix a UI. Setting up a mock server for that can feel like too much ceremony.

2. Local fixtures
Local fixtures are fast and simple.

You create a JSON file, import it somewhere, and render the UI against that data.

Fixtures can also drift from real API responses over time.

3. Backend flags or test endpoints
Sometimes the backend team can add a flag, seed special data, or expose a test endpoint. That can be useful, especially in mature teams. But it also creates coordination overhead. The frontend developer has to ask for the state, wait for it, and hope it still exists when QA or design tries to reproduce the same thing later.

4. Browser hacks
We have all done some version of this. Add a temporary throw. Edit code in DevTools. Comment out a fetch call. Hardcode a response. Change a local branch just to force an error state.

It works, but it is fragile. It is also easy to forget, hard to share, and not something you want to rely on for repeatable testing.

A lighter workflow: override the response locally

For many frontend tasks, the ideal workflow is smaller:

Open the app.
See the real request the app is making.
Choose the request you want to control.
Return the response you need.
Reload and test the UI.

No backend change. No proxy setup. No full mock server. No app code changes.
Just one local override for one real browser request.
That is the workflow I have been thinking about while building Ruse.

Example states worth testing

Here are a few states I think every production UI should be easy to test.

Empty list

{
  "items": []
}

Does the UI show a thoughtful empty state? Is the CTA correct? Does the layout collapse awkwardly? Does pagination disappear?

Server error

{
  "error": "Internal server error"
}

Does the page recover? Can the user retry? Is the message useful? Does the app accidentally show a blank screen?

Slow response
A slow API often reveals problems that fast local development hides.

Do loading indicators appear? Do buttons stay disabled? Does the page jump when data arrives? Can the user trigger duplicate actions?

Malformed response

{
  "items": null
}

This is where defensive UI code gets tested.

Does the app fail gracefully, or does one unexpected value take down the entire screen?

Permission error

{
  "error": "You do not have access to this resource"
}

Permission states are product states too. They need design, copy, and behavior.

Why browser-level mocking is useful

Mocking at the browser level is interesting because it starts from what your app is actually doing.

That makes the loop feel more natural for frontend work.

It is especially useful when you are:

building UI before the backend is complete
testing error states
preparing stable demos
reproducing QA bugs
checking loading behavior
designing empty states
working against flaky staging data

Where Ruse fits

I am building Ruse as a Chrome extension for this workflow.

The idea is simple:

inspect browser requests
create local mock rules
return custom responses
test the UI state you need
keep everything local in the browser The first release is intentionally small and local-first. It is not trying to be a full API platform. It is focused on making the first useful mock fast.

Ruse is currently in alpha and going through Chrome Web Store review.

If this workflow sounds useful, I am looking for early testers:

https://ruse.dev/support?topic=early-access

Final thought

Frontend edge cases should not require a backend meeting.

Sometimes you need a full mock server. Sometimes you need contract testing. Sometimes you need proper seeded environments.

But sometimes you just need one request to return one different response so you can finish the UI in front of you.

That small loop is worth making better.