Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MSW 2.0 – Mock Service Worker

mswjs.io

Post reply on HN
Print view View original

51–60 of 61 posts

Re: MSW 2.0 – Mock Service Worker

#51

Post by scottlamb »

How do folks test timing-related stuff with MSW? AFAIK, MSW doesn't get along with jest.useFakeTimers. It drives me nuts; I have a bunch of disabled tests in an open-source project and at least one that is flaky because it uses real timers where I'd like to be using fake timers. [1, 2]

I've been thinking about ripping out MSW from my tests in favor of my own API-level mock for this reason. But it seems like many other folks are happy with MSW. I have to assume there's something I'm not getting. I'm a fish out of water with frontend stuff in general...

[1] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

[2] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

Re: MSW 2.0 – Mock Service Worker

#52

Post by t1mmen »

dcre wrote: post #21

At my job we've found working with MSW + OpenAPI to be near miraculous. I work on a web frontend and do most of my development against a mock API powered by MSW. This live preview runs against the mock API running fully in-browser. https://oxide-console-preview.vercel.app More details: https://github.com/oxidecomputer/oxide.ts https://github.com/oxidecomputer/console https://oxide.computer/podcasts/oxide-and-friends/…

Really cool setup, thanks for sharing!

After buying in to OpenAPI as the fundamental source of truth (generated via https://www.ts-rest.com contracts in my case), I have radically changed how I think about web development.

At this point, it's frankly absurd to me how many people out there make it so hard for themselves by manually building/typing/validating both client & server-side responsibilities in most typical REST setups. I get it -- I spent >2 decades in that reality, but no more. I will die on this hill.

I am likely understating the impact when I say I'm 2x as productive whenever I touch API related functionality/validation on client or server-side.

MSW, Zod, react-hook-form+ZodResolver and several other tools in the OpenAPI ecosystem are simply incredible for productivity. The project I'm on now is certainly the most fun I've ever built because of these amazing tools.

Re: MSW 2.0 – Mock Service Worker

#53

Post by smallerfish »

codybontecou wrote: post #44
smallerfish wrote: post #41

Earlier quoted context omitted.

Guess we are stuck with surfline. I'd be interested in creating a competitor if I knew more about the data sources though - fun problem.

Stormsurf provides tutorials and public data source links if you are genuinely curious: http://stormsurf.com/page2/tutorials/menu.html

Cool, thanks. Bookmarked for a weekend.

Re: MSW 2.0 – Mock Service Worker

#54

Post by abalashov »

ok123456 wrote: post #25

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

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.

Re: MSW 2.0 – Mock Service Worker

#55

Post by dcre »

ok123456 wrote: post #25

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

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

Re: MSW 2.0 – Mock Service Worker

#56

Post by adam_beck »

wdb wrote: post #47
ushakov wrote: post #35

Earlier quoted context omitted.

Amazing. At Step CI we’re currently working on a tool that will do the conversion automatically (OpenAPI > MSW) Feel free to email me at mish@stepci.com if you want to hear more!

Why not use @mswjs/source?

I've seen you mention this a few times but can't seem to find any information on it. I'm very interested in being able to use HAR files with MSW.

Re: MSW 2.0 – Mock Service Worker

#57

Post by szines »

ok123456 wrote: post #25

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

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...

Re: MSW 2.0 – Mock Service Worker

#58

Post by Klaster_1 »

ljm wrote: post #33
ok123456 wrote: post #25

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…

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.

Re: MSW 2.0 – Mock Service Worker

#59

Post by ljm »

Klaster_1 wrote: post #58
ljm wrote: post #33

Earlier quoted context omitted.

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…

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, a…

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.

Re: MSW 2.0 – Mock Service Worker

#60

Post by c01nd01r »

wdb wrote: post #47
ushakov wrote: post #35

Earlier quoted context omitted.

Amazing. At Step CI we’re currently working on a tool that will do the conversion automatically (OpenAPI > MSW) Feel free to email me at mish@stepci.com if you want to hear more!

Why not use @mswjs/source?

Could you provide a link to this package? I can't seem to find anything.
Post reply on HN