Great question! When I started Mirage this was the biggest concern, but after years of usage it turns out to not be that big of a deal in practice. Said another way, the benefits of being able to easily write high-level UI tests for a variety of server states all within your frontend codebase outweigh the costs of potential false positives. Also, teams don't break their HTTP APIs that often.
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.
Hello! I'm Sam and I built Mirage JS to be a framework-agnostic API mocking library.
Mirage is extracted it from an addon that's been widely used in the Ember ecosystem for the past 4 years, at companies like Apple, Heroku, Square and Footlocker.
Nearly all frontends need to talk to an API, no matter what framework they're built with! So over the past year I've made Mirage work with any tool or test runner.
I really believe deeply in the frontend-first workflow, and Mirage makes that easier than ever. If it sounds interesting to you, check out the lib + let me know what you think!
- Robust relationship support (many-to-many, one-to-one, polymorphic, reflexive)
- GH project organization. Now that projects have landed, we need to move non-actionable issues into notes on an "Ideas" project, and clean up the issues backlog.
Wanted to second Sowell's works, surprised to see him mentioned only once here. He's very accessible and values simplicity and clarity above all else in his writing. As he says,
"If academic writings were difficult because of the deep thoughts involved, that might be understandable, even if frustrating. Seldom is that the case, however. Jaw-breaking words often cover up very sloppy thinking. It is not uncommon in academic writings to read about people “living below subsistence.” The academic writers I edited seemed to have great difficulty accepting my novel and controversial literary doctrine that the whole purpose of writing is so that people can read the stuff later on and know what you are trying to say. These professors seemed to feel that, once they put their priceless contributions to mankind on paper, a sacred obligation fell upon the reader to do his damndest to try to figure out what they could possibly mean."
A client-side mock server to develop, test and prototype your Ember app
Monthly Goals:
- Unify the {json:api} serializer with the base layer
- Robust relationship support (many-to-many, one-to-one, polymorphic, reflexive)
- Add factory traits and relationships
Absolutely, I wasn't saying that farmers in pre-industrial America didn't contribute anything. My point was that once tech displaced the majority of their jobs, they didn't all just sit around and not do anything.
Technology freed up their labor from producing food and allowed them to produce things like automobiles, textiles and eventually computers. The idea that new tech will leave large parts of the population with absolutely nothing to do has been suggested before, but we still have no example of it actually happening, and in fact, far more examples of the reverse.
I don't think the alternative is to sit around and do nothing. Economies are much more dynamic than that, and while it's true some may suffer in the short-run, it's wouldn't be like that forever.
At one point the US was primarily an agrarian society, and more than 90% of labor worked on a farm. Imagine telling someone from that society that some day, tech would allow less than 2% of the workforce to produce many times more food than the current total output. I'm sure they would express a similar concern, though we know they'd be wrong.