Sanjay Selvaraj Posted on May 31 MSW vs Hosted Mock APIs: When To Use Each # api # testing # webdev # opensource A few weeks ago I was working on a frontend flow that depended on several backend APIs. For local development, MSW was perfect. I could intercept requests, return whatever data I wanted, and keep moving without waiting for backend work. The problems started when other people got involved. QA wanted to test the same flow. A product manager wanted a demo environment. We needed a webhook endpoint for an external service. Suddenly my local mocks weren't very useful anymore. That got me thinking about where local mocking tools end and where hosted mocks start. MSW Is Excellent I'm not writing this as an MSW critic. MSW is probably one of the best developer tools I've used for frontend work. A few things it does really well: No backend required Works directly in the browser Great for component testing Great for integration tests Easy to simulate different API responses If I'm building a React feature and just need to unblock myself, MSW is usually my first choice. Where Local Mocks Start To Struggle The challenge isn't creating mocks. The challenge is sharing them. Imagine this setup: Frontend developer using MSW locally QA team testing in a separate environment Backend team still building APIs Product team reviewing features External webhook integrations Now everyone needs access to the same API behavior. A mock that only exists on one laptop becomes difficult to coordinate. Where Hosted Mock APIs Help Hosted mocks solve a different problem. Instead of intercepting requests locally, they expose real HTTPS endpoints. That means: QA can use them Demo environments can use them CI pipelines can use them Third-party services can send webhooks to them The tradeoff is that you're introducing infrastructure where MSW requires none. The Bigger Problem Nobody Talks About While comparing local and hosted mocks, I kept running into another issue. Mocks slowly drift away f
LIVE