Comparison
Carbon vs MSW
MSW is the de-facto request-mocking library for JavaScript apps. It intercepts fetch/XHR in the browser via a Service Worker and in Node via request-level hooks, and it is excellent for component and unit tests where you want a handful of endpoints stubbed with a couple of lines of code. Carbon plays a different role: it is a real HTTP server that models the whole API and holds state across requests, which is where MSW starts to feel hand-rolled.
Capability by capability
Rows below are checked against MSW's public docs. Where support is "partial" we say what's actually there.
| Capability | Carbon | MSW | Notes |
|---|---|---|---|
| State persistence across requests | Possible by hand — you write the store yourself inside a handler. | ||
| Snapshots / rewind (state journal) | |||
| Chaos / failure injection | You can throw or return a 500 in a handler; no first-class latency/chaos presets. | ||
| Multi-format ingest (OpenAPI, GraphQL, HAR, Postman, gRPC) | GraphQL and REST handlers ship in-box; other formats need adapters. | ||
| Local-first (runs on your laptop) | |||
| No hosted-service dependency | |||
| Framework glue (vitest, jest, playwright) | |||
| Drift detection vs real API |
When to pick MSW
- You only need to stub a few endpoints inside a browser component test.
- You want mocks to live inline with the JS test file, not as a separate process.
- Your codebase is already invested in MSW handlers and you like maintaining them by hand.
When to pick Carbon
- You need a real server on a port so non-JS clients (curl, Postman, your Go microservice) can hit it too.
- You want state, snapshots, and rewind without writing the store yourself.
- You want chaos presets and drift detection out of the box, not as bespoke handler code.
Try Carbon against your own spec.
One command turns any OpenAPI, GraphQL, HAR, Postman, or gRPC spec into a stateful local server. See how it compares to MSW on the endpoints you actually ship.