I have another question. Mirage is installed as a dev dependency. But all the examples show it being used in the application code. Do you maintain a separate branch without the import of Server, etc? Or is webpack smart enough to remove all imports/usage of dev dependencies in the prod build? I don't think I've ever imported dev dependencies into app code before.
For that matter, how does it provide a sanity check between what the back end delivers and the front end expects? Do you mean compared to coding to a spec with no mocking? Like when the back end doesn't exist yet?
Clearly I'm missing something. Could be the sleep deprivation.
Even so, there are teams that have used tools like Pact to perform contract testing, ensuring their Mirage server and their production API never fall out of sync. Even more exciting to me would be using something like Typescript to verify the API contract at compile-time (also something that others have been exploring).
As far as only running Mirage during development, the Ember addon does this but we need to document how to do this in the general case. When you build your app for production Mirage should not be in any application code, nor should the miragejs library be included in your bundle. Webpack is capable of this, we just need to document it.
Mirage is flexible enough to match any backend API – this is where it shines in comparison to tools like json-server. With Mirage the goal is to mock out your exact production API; its serializers and route handlers can be customized to match any API format. Often teams using Mirage reach agreement about the shape of their API beforehand, precisely so that the frontend team can move and build the UI without having to wait on the API to be ready.
Indeed, Mirage can even be thought of as a communication tool that helps impose conventions and consistency on the API layer, making both the frontend developers and the backend developers happier.
The team I work on have been using Mirage with GraphQL for 6 months or so and GraphQL’s tooling almost entirely addresses this question. There will still be false positives in API behaviour (you can never have a completely accurate simulation) but you can get an incredible degree of confidence at a startlingly low cost, with a delight developer experience to boot. Similar strategies could no doubt be employed for JSONSchema, Swagger, or Pact tooling.