MSW vs Hosted Mock APIs: When To Use Each

Sanjay Selvaraj — Sun, 31 May 2026 17:47:16 +0000

A few weeks ago I was working on a frontend flow that depended on several backend APIs.

For local development, MSW was perfect. I could intercept requests, return whatever data I wanted, and keep moving without waiting for backend work.

The problems started when other people got involved.

QA wanted to test the same flow.

A product manager wanted a demo environment.

We needed a webhook endpoint for an external service.

Suddenly my local mocks weren't very useful anymore.

That got me thinking about where local mocking tools end and where hosted mocks start.

MSW Is Excellent

I'm not writing this as an MSW critic.

MSW is probably one of the best developer tools I've used for frontend work.

A few things it does really well:

No backend required
Works directly in the browser
Great for component testing
Great for integration tests
Easy to simulate different API responses

If I'm building a React feature and just need to unblock myself, MSW is usually my first choice.

Where Local Mocks Start To Struggle

The challenge isn't creating mocks.

The challenge is sharing them.

Imagine this setup:

Frontend developer using MSW locally
QA team testing in a separate environment
Backend team still building APIs
Product team reviewing features
External webhook integrations

Now everyone needs access to the same API behavior.

A mock that only exists on one laptop becomes difficult to coordinate.

Where Hosted Mock APIs Help

Hosted mocks solve a different problem.

Instead of intercepting requests locally, they expose real HTTPS endpoints.

That means:

QA can use them
Demo environments can use them
CI pipelines can use them
Third-party services can send webhooks to them

The tradeoff is that you're introducing infrastructure where MSW requires none.

The Bigger Problem Nobody Talks About

While comparing local and hosted mocks, I kept running into another issue.

Mocks slowly drift away from reality.

A field gets removed.

A type changes.

The real API evolves.

Meanwhile the mock keeps returning the old response.

Tests pass.

Everything looks fine.

Until production doesn't.

Creating mocks turned out to be easy.

Keeping them trustworthy was the harder problem.

So Which Should You Choose?

My rule of thumb is simple.

Use MSW when:

You're developing locally
You're testing frontend behavior
You want fast feedback

Use hosted mocks when:

Multiple people need the same endpoint
You need public URLs
You need webhook testing
You need shared environments

In practice, many teams end up using both.

MSW for local development.

Hosted mocks for collaboration and integrations.

Final Thoughts

I don't think this is an MSW versus hosted mocks debate.

They're solving different problems.

The interesting challenge starts later, when teams have to keep mocks, contracts, and real APIs aligned as systems evolve.

That's where I've seen the biggest pain points appear.

Why I Started Looking Into This

A lot of these observations came from building Thodr, a hosted mock API platform for frontend, QA, and integration workflows.

The original goal was simply to make it easier to create and share mock APIs.

What surprised me was that creating mocks wasn't the hard problem.

Keeping mocks aligned with real APIs turned out to be far more challenging, especially as projects, environments, and teams grew.

That's what led me to start exploring things like contract drift detection and automated validation.

[Boost]

Sanjay Selvaraj — Sun, 31 May 2026 17:40:17 +0000

DEV Community: Sanjay Selvaraj