Mock Service Worker (MSW) is set up with setupWorker in the browser and setupServer in Node. What actually intercepts the request in each environment, and why can both be handed the same array of handlers?

## One description, two interception mechanisms MSW's design separates *what to mock* from *how the request is caught*. The handler array is the what; `setupWorker` and `setupServer` are the two hows, chosen by environment. ## The browser: a real service worker A service worker is a browser-provided script that can sit between a page and the network and observe or answer its requests. MSW ships a generated worker script — `mockServiceWorker.js`, copied into your public directory by its CLI — that does nothing clever on its own: it forwards every request the page makes to the MSW client library running on the page, waits for a verdict, and either replies with the mocked response or lets the request continue to the real network. ```js import { setupWorker } from 'msw/browser' import { handlers } from './handlers' const worker = setupWorker(...handlers) await worker.start() ``` Three consequences follow. First, the request is real all the way out of the application: devtools show it in the network panel, timing exists, and the response your code parses came back through the same path a production response would. Second, the worker script must be reachable at the right URL — if it is not served from the public directory the app is served from, `start()` cannot register it and nothing is mocked. Third, `worker.start()` is asynchronous, so requests fired before it settles escape interception; that is why app entry points await it before rendering, and why a test that renders too early sees real network calls. This setup is what you use for in-browser work: a development mode that runs the UI against fixtures with no backend, a component workshop, or an in-browser component-test runner. ## Node: patching the request primitives A jsdom test environment is not a browser. It has no service worker implementation at all, so the browser mechanism simply cannot apply. `setupServer` — the name is misleading; it starts no HTTP server — instead instruments the objects that issue requests inside the process: Node's `http`/`https` request machinery, the `XMLHttpRequest` jsdom provides, and global `fetch`. Any request made through those, by your code or by a client library sitting on top of them, is routed to the same handler list. ```js import { setupServer } from 'msw/node' import { handlers } from './handlers' export const server = setupServer(...handlers) ``` The lifecycle is explicit and belongs in the suite's setup file: start the interception before the tests run, drop per-test overrides between tests, and stop the interception at the end. Because interception is process-wide, forgetting to stop it leaks into whatever runs next in the same process. ## Why the handlers are shared A handler carries no knowledge of its environment. `http.get('/api/users', () => HttpResponse.json(users))` names a method, a path and a response — the same three facts whether the request is caught by a service worker or by a patched `fetch`. So the honest project layout is one `handlers.js` (or a folder of them, one per resource) exported as a plain array, imported by `browser.js` for `setupWorker` and by the test setup file for `setupServer`. That sharing is the practical payoff. The fixtures your unit tests assert against are the same fixtures the app renders in offline development mode, so a stale fixture is discovered by whoever hits it first, and the two never drift into two competing pictures of the API. ## What differs in practice Fidelity: the worker path exercises the whole browser network stack, including things a patched `fetch` does not perfectly reproduce; the Node path is faster and needs no browser. Debuggability: the worker shows requests in devtools, while in Node you rely on MSW's lifecycle events and console output. Scope: the worker only intercepts requests from pages it controls, whereas `setupServer` covers everything issued in the process, including requests from server-side code in the same run. Timing: `worker.start()` must be awaited; `server.listen()` is synchronous. ## The interview point The answer an interviewer is listening for is not the two function names — it is that the *same declarative handlers* are portable across environments because interception is an implementation detail, and that you know which environment forces which mechanism and why. A candidate who says "setupServer spins up a mock HTTP server on a port" has the mental model wrong: nothing listens on a port, and no URL changes.