Hacker News Reader

Comment by ok123456 | Hacker News Reader

What is the benefit of using MSW over mocking a service with a small express server?

You can generate TS from an OpenAPI spec and then create type-safe mocks of network calls.

Basic mocks and fake servers run the risk of falling out of sync and giving false positives, or just being outright wrong to short-cut some of the work. It's also less code to maintain when a service worker can intercept the call, instead of orchestrating a load of mock APIs.

It won't stop you making breaking changes on the API but it will keep you honest on consuming the API on the client.

Too bad this only gets you so far. Last time I checked, the OpenAPI specs are not as flexible as TS types and the people who author these - probably the team members responsible for the backend - won't necessarily even be able to list all the invariants due to framework and host language constraints. And OpenAPI does not support WebSockets. The project I work on has a frontend written in TypeScript, a Java backend, an Express-based dev-server that shares same types with FE, but none of the solutions the team evaluated enables the type sharing across all three beyond simple "an object can have these fields" - no algebraic data types, no WebSocket support. In the end, we resorted to agreeing on as much as possible in plain text before greenlighting the new endpoint, and then double checking the implementation and client usage for unexpected behaviors.

For those use-cases you might just be better off with either contract tests or simply making the payload itself typesafe with something like protobuf.

OpenAPI/Swagger is basically inextricably bound to REST/JSON APIs over HTTP. I also think they're quite abstruse in terms of defining non-trivial interfaces.

No need to run a small express server? MSW runs in the browser so you can develop against a mocked API.

One of the biggest advantages of MSW, is that you can use the same mock server in your unit tests (jest) on Node.js environment and run the full frontend in the Browser for development and preview.

The best if you have totally the same mock data, so super easy to debug your tests.

Also, you can use this trick to have scenarios, so you can demo different behaviours just by passing a query param. QA loves it as well.

https://github.com/zoltan-nz/meetup-contacts-app-2021/blob/m...

For me, the fact that every dev server tab I open is its own fresh server instance is really useful. We can run our tests in parallel with no server. We can deploy a live preview as a static site.

https://oxide-console-preview.vercel.app/projects

I have the same question. I just use a small local container fleet (Docker Compose) and have my actual API server running, and have never seen this to be a problem. I can do all this local development without depending on connectivity, etc.

Reply on news.ycombinator.com