Mockfly vs MSW: a hosted mock server or in-process interception?

Mock Service Worker (MSW) and Mockfly solve the same problem, an API that is not there yet, from opposite ends. MSW intercepts requests inside your JavaScript. Mockfly answers them from a URL on the internet. Most frontend teams end up wanting both; this page explains which one to reach for and when.

What MSW is

MSW is an open-source library that intercepts HTTP requests at the network level of your own process: a Service Worker in the browser, request interceptors in Node. You describe handlers in code, next to your tests or your app, and the request never leaves the machine. It is framework-agnostic, works in Jest, Vitest, Playwright and Storybook, and the same handlers run in the browser during development.

Its strength is that the mock lives with the code: versioned, reviewed, typed if you want, and free of any network. Its limit is the same fact: the mock only exists where that code runs.

What a hosted mock server adds

• One URL for everyone. The iOS app, the Android app, the backend service that calls the API, the QA engineer with Postman and the designer clicking through a prototype all hit the same mock.
• No code to change a response. A product manager or a tester can flip an endpoint from 200 to 500, edit a body or add a rule in the UI. With MSW that is a pull request.
• Realistic data without writing it. Faker.js templates re-evaluate on every request and the AI can generate a whole payload from a sentence. MSW can use Faker too, but you wire it yourself.
• Import the contract. Drop in the OpenAPI spec or the Postman collection and every path is an endpoint. With MSW you write, or generate, a handler per route.
• Logs and documentation. See every request the mock received, share auto-generated docs with the backend team, and proxy the endpoints that already exist to the real API.

Where MSW is simply better

• Unit and component tests: no network, no flakiness, no rate limits.
• Offline development on a plane, without the Mockfly CLI.
• Type-safe handlers that fail the build when the API contract changes.
• Anything where the mock must ship inside the repository and nowhere else.

Features comparison

A sensible setup for a frontend team

1. Agree the contract with the backend team as an OpenAPI spec.
2. Import the spec into Mockfly. Point the app at the project URL through an environment variable so switching to the real API later is a one-line change.
3. Generate MSW handlers from the same spec for unit tests, so both mocks describe the same API.
4. When the backend ships an endpoint, switch that endpoint to proxy mode and leave the rest mocked.

Start with the free plan at app.mockfly.dev, or read how to mock API calls in React for working code with fetch, Axios and MSW.

Frequently asked questions