APIFae and MSW

MSW and APIFae are different kinds of tool, and a team can use both. MSW intercepts requests inside your app or test process: a service worker in the browser, request interception in Node. APIFae is a separate mock server that anything on your network can call, and apifae diff checks its mocks against the live API.

This page says where each one fits. Every claim about MSW below links to the documentation page it came from.

Use MSW for

  • Component and unit tests that run in the same process as your code. MSW starts no separate server.
  • Mocking requests in the browser itself, through a service worker.
  • Reusing the same handlers across your test runner, browser tests and demos.
  • Typed handlers written next to your frontend code.
  • An open-source library. MSW is licensed under MIT.

Use APIFae for

  • Anything outside your process that needs the mock: another service, a phone, a teammate, or curl. apifae up serves your mocks over HTTP.
  • Knowing when your mocks stop matching the real API. apifae diff compares each mock with the live API, and it works without an OpenAPI spec.
  • A CI gate that tells drift apart from an outage. apifae diff exits 1 when a mock has drifted and 2 when it can't reach the API.

Use MSW inside your tests, and APIFae wherever a real HTTP server is needed.

Read from MSW’s own documentation on . What each row is based on.
CapabilityAPIFaeMSW (opens in a new tab)
Where it runsA separate server processInside your app or test process
Reachable from other processes and devicesYes, over HTTPNot by default. An add-on can start a server
Mocks requests inside the browserNoYes, through a service worker
Creates mocks from recorded trafficYes, apifae recordFrom a HAR file, with a separate package
Checks mocks against the live APIYes, apifae diffNo. Its docs suggest regenerating mocks in CI
LicenceClosed source; binaries under MIT or Apache-2.0MIT

The MSW docs cover keeping mocks up to date. They treat the spec as the source of truth and suggest a CI job that regenerates snapshots. apifae diff takes the other approach and checks mocks against the running API.

Where each claim comes from

Checked against MSW’s documentation on . If a quote no longer matches the page it links to, the claim is out of date and we want to hear about it.

  1. Use MSW for

    Component and unit tests that run in the same process as your code. MSW starts no separate server.

    Despite the word "server" in the name, it does not establish any servers, operating entirely in the thread of your process
    https://mswjs.io/docs/api/setup-server (opens in a new tab)

    Mocking requests in the browser itself, through a service worker.

    In the browser, MSW works by registering a Service Worker responsible for request interception on the network level
    https://mswjs.io/docs/integrations/browser (opens in a new tab)

    Reusing the same handlers across your test runner, browser tests and demos.

    Reuse the same mocks across environments and tools, be it an integration test with Vitest, an automated browser test with Playwright, a demo showcase in Storybook, or a React Native app
    https://mswjs.io/ (opens in a new tab)

    Typed handlers written next to your frontend code.

    Mock Service Worker facilitates type-safe API mocking through generic arguments in TypeScript
    https://mswjs.io/docs/best-practices/typescript (opens in a new tab)

    An open-source library. MSW is licensed under MIT.

    MIT License Copyright (c) 2018–present Artem Zakharchenko
    https://github.com/mswjs/msw/blob/main/LICENSE.md (opens in a new tab)
  2. Where it runs

    Inside your app or test process

    Despite the word "server" in the name, it does not establish any servers, operating entirely in the thread of your process
    https://mswjs.io/docs/api/setup-server (opens in a new tab)
  3. Reachable from other processes and devices

    Not by default. An add-on can start a server

    Spawn an Express server from your Mock Service Worker request handlers
    https://github.com/mswjs/http-middleware (opens in a new tab)
  4. Mocks requests inside the browser

    Yes, through a service worker

    In the browser, MSW works by registering a Service Worker responsible for request interception on the network level
    https://mswjs.io/docs/integrations/browser (opens in a new tab)
  5. Creates mocks from recorded traffic

    From a HAR file, with a separate package

    Generate MSW request handlers from HAR files, OpenAPI documents, and other sources
    https://github.com/mswjs/source (opens in a new tab)
  6. Checks mocks against the live API

    No. Its docs suggest regenerating mocks in CI

    Treating the backend runtime as the truth is prone to issues … consider automating the process by configuring your CI to regularly update the specification/network snapshots
    https://mswjs.io/docs/recipes/keeping-mocks-in-sync (opens in a new tab)
  7. Licence

    MIT

    MIT License Copyright (c) 2018–present Artem Zakharchenko
    https://github.com/mswjs/msw/blob/main/LICENSE.md (opens in a new tab)
  8. Keeping mocks in sync

    The MSW docs cover keeping mocks up to date. They treat the spec as the source of truth and suggest a CI job that regenerates snapshots. apifae diff takes the other approach and checks mocks against the running API.

    Treating the backend runtime as the truth is prone to issues … consider automating the process by configuring your CI to regularly update the specification/network snapshots
    https://mswjs.io/docs/recipes/keeping-mocks-in-sync (opens in a new tab)

Our own column

The APIFae cells have no quotes because you can check them by running the binary. The full comparison puts APIFae next to WireMock, Prism and Mockoon, and the guide to keeping a mock honest walks through a real apifae diff run against a live API.