For a second I thought it was Magic Seaweed 2. RIP.
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.
MSW 2.0 – Mock Service Worker
41–50 of 61 posts
Re: MSW 2.0 – Mock Service Worker
#42Earlier 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!
We more or less did that too. We generate typed wrappers for every handler, and then we manually implement the internal logic for each endpoint. I doubt reliably generating 100% of the logic is possible, but even if it is, I would guess it's more work to do that than to do it manually. Generator: https://github.com/oxidecomputer/oxide.ts/blob/64401fa2/gene... Generated output: https://github.com/oxidecomputer/console…
I'm so glad to see all of your comments here. I've been fascinated by your setup ever since hearing about it on the Oxide and Friends podcast. The part that I'm most curious about is the part where you weave together auto-generated interface code with hand-implemented mock implementations… I'll have to go read your code and see how that happens.
[Edit, after reading a bit of the code]
Am I correct in understanding that the generated code maps API calls to a typed interface, and then the hand-built implementation simply implements that interface?
So rather than complex weaving where you want hand-coded function bodies but generated signatures, you have generated signatures, where each function body calls a method on a generated interface.
Re: MSW 2.0 – Mock Service Worker
#43Earlier quoted context omitted.
We more or less did that too. We generate typed wrappers for every handler, and then we manually implement the internal logic for each endpoint. I doubt reliably generating 100% of the logic is possible, but even if it is, I would guess it's more work to do that than to do it manually. Generator: https://github.com/oxidecomputer/oxide.ts/blob/64401fa2/gene... Generated output: https://github.com/oxidecomputer/console…
I'm so glad to see all of your comments here. I've been fascinated by your setup ever since hearing about it on the Oxide and Friends podcast. The part that I'm most curious about is the part where you weave together auto-generated interface code with hand-implemented mock implementations… I'll have to go read your code and see how that happens. [Edit, after reading a bit of the code] Am I correct in understanding th…
Yeah, basically. We do it with a function call where the argument to the function is that interface representing all the API endpoints. `makeHandlers` handles parsing path params, query params, and request body and passes them to each endpoint handler. So the runtime validation of request bodies is also generated — we generate a zod schema for each request body in the OpenAPI definition and use it to parse the actual request body that comes in. So it's not just a generated interface — there is also generated runtime behavior that is endpoint-specific.
big function call https://github.com/oxidecomputer/console/blob/bd65b9da7019ad...
automatic body parsing and argument passing: https://github.com/oxidecomputer/console/blob/bd65b9da7019ad...
When an endpoint gets added to the spec, we can rerun the generator and get type errors in the `makeHandlers` telling us endpdoints are missing.
Re: MSW 2.0 – Mock Service Worker
#44For a second I thought it was Magic Seaweed 2. RIP.
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
Re: MSW 2.0 – Mock Service Worker
#45Earlier quoted context omitted.
That's a lot of time and effort, for people earning next to nothing, for an open-source library. I'm not saying it's bad they have a beautiful website to rival any small SaaS, but how is even possible they have the time and energy to spend on that, rather than on the code itself? What would Linux or GNOME or leftpad look like with a proportional amount of marketing effort? Last time I checked, testing libraries did n…
I think this is actually pretty common in the JavaScript ecosystem. Presumably, because contributors are very skilled in building websites and maybe also because users have higher expectations when it comes to presentation. I mean checkout https://vitest.dev/ https://jestjs.io/ https://webdriver.io/de/ https://playwright.dev/ (all testing related stuff).
I agree. Beautiful documentation helped me a lot early on when getting into the JS ecosystem.
Re: MSW 2.0 – Mock Service Worker
#46At 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/…
Yeah, @msw/source is pretty sweet for that :)
Use a .har or OpenAPI spec to create mock handlers
Re: MSW 2.0 – Mock Service Worker
#47At 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/…
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?
Re: MSW 2.0 – Mock Service Worker
#48At 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/…
we started using (and now contributing to) https://orval.dev/ this year which both generates the mocks using MSW as well as the client-side networking code (React Query in our case). It removes so much boilerplate its amazing.
wrote up the basics of our workflow few weeks ago https://betaacid.co/blog/api-contracts
Re: MSW 2.0 – Mock Service Worker
#49Earlier quoted context omitted.
Just when I think I get the whacky web kids, hell, that maybe I've even one of them, an article like this and functionality like this comes along. I don't know how a mock library enables a revolution of having test data. I don't know why the library couldn't change it's favorite method signature because a subset of versions of one JS framework couldn't...fetch? or why the mock library can only have one dependency...…
Worth noting that in my experience it's the combination of MSW and code generated from an OpenAPI spec that really makes it special, not just MSW alone. The other reply covers it but I want to slice it slightly differently. I see two things that are different here. One is mocking at the HTTP boundary rather than mocking, e.g., function return values or modules or whatever. That's certainly not revolutionary (I know p…
Thank you __very__ much, I went a bit long to try to signal I was serious and thought I wouldn't get any substantive reply. This is beyond my wildest dreams. Thanks again.
Re: MSW 2.0 – Mock Service Worker
#50At 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/…
we started using (and now contributing to) https://orval.dev/ this year which both generates the mocks using MSW as well as the client-side networking code (React Query in our case). It removes so much boilerplate its amazing. wrote up the basics of our workflow few weeks ago https://betaacid.co/blog/api-contracts
Orval is great, I also recently wrapped up a project with Orval, React Query, and MSW. Generated my typescript models, helped me track changes in the API each time I updated against the swagger spec and let me test and demo the UI before our API team had a server running. Such a time-saver.