[cbhl]

The first page of the docs list a few reasons.

https://miragejs.com/docs/getting-started/introduction

"Use a client-side interceptor to handle your app's network requests. ... This is the most flexible approach, but it requires you to start from scratch in each project, and leaves it up to you to enforce conventions across your apps."

"Importantly, because Mirage mocks the HTTP boundary instead of the JavaScript code your app uses to make network requests, you never need to modify your application code to account for whether your app is talking to Mirage or to your real production backend."

[rclayton]

How is this the best/most flexible approach? What if you decide to move from REST to GQL? GQL to websockets? By mocking the HTTP endpoint you’re too low in the stack. At that point, I feel like you might have better success with using the actual backend and swap out the DB with mock data.

[KitDuncan]

I always use this approach for my E2E tests. This way I test the backend as well as the frontend. Harder to setup properly though.