MirageJS: An API mocking library for frontend development

Hello! I&#x27;m Sam and I built Mirage JS to be a framework-agnostic API mocking library.<p>Mirage is extracted it from an addon that&#x27;s been widely used in the Ember ecosystem for the past 4 years, at companies like Apple, Heroku, Square and Footlocker.<p>Nearly all frontends need to talk to an API, no matter what framework they&#x27;re built with! So over the past year I&#x27;ve made Mirage work with any tool or test runner.<p>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!

I believe Michael Feathers was just started a Twitter thread yesterday that talked, among other things, about moving IO to the edges of your code.<p>If you can divide acquisition from usage, I wonder how much less effort you need to put into API mocking.<p>Ages ago and shortly after I started testing, was the last time I had to do any low-level HTTP response processing. My coworkers could not fathom why I had divided the parsing and networking code into completely separate sections. Then I showed them how stupid-simple most of the tests were, instead of the convoluted mess of integration tests I&#x27;d walked into.<p>Hand the payload to I&#x2F;O-free code immediately. You&#x27;ve done the hardest part at this point. Mocking out the network layer in any of half a dozen ways is a cakewalk in comparison.

What is the benefit of a request mocking framework versus hiding all api requests behind a module?<p>Instead of<p><pre><code> &#x2F;&#x2F; MyComponent.js const users = await fetch(... </code></pre> Use this<p><pre><code> &#x2F;&#x2F; MyComponent.js const users = await api.getUsers() &#x2F;&#x2F; api.js export default { getUsers() { return fetch(... } } </code></pre> To mock, you replace the entire api module (or individual functions).

Just my two cents: Mirage is freaking great because it makes mocking shit out pretty much as easy as possible and pretty damn correct.<p>I don&#x27;t know how many times mocking up a UI I start to throw some random JS objects in a file and then inevitably after a few hours, those random JS objects are unmanageable and contain very small differences between what my API will deliver.<p>Using Mirage from the start of projects has made my life a lot easier, it also provides a nice sanity check between what the backend delivers and what the frontend actually expects.

Mirage is a staple of Ember development. It&#x27;s one of those things I didn&#x27;t realize I was missing until I learned it, and now I can&#x27;t imagine not using it(at least in early development). I kinda didn&#x27;t realize I could use it outside of Ember CLI, so this is pretty cool.

I&#x27;ve used mirage extensively throughout the past 5+ years across multiple projects&#x2F;teams and it truly is a great tool. In a recent project we had multiple &quot;scenarios&quot; defined that represented different high-level states of the app. We added a page that allowed switching between the scenarios during local development and it was a huge boon to productivity, while also allowing us to write certain automated smoke tests that otherwise would have been more cumbersome with e.g. selenium.<p>Working on a React project recently, I was surprised that there wasn&#x27;t an option like mirage, but now that there is, I highly recommend it!

I would rather make a component that takes data as props.<p>Now make a component on top that runs a network request and injects the network response into it.<p>Now you have a reusable component independent of the api. Your network function can be tested individually. Your top level component doesn’t need testing as that is the part that would be mocked.<p>You can now test your actual component without any mocking.<p>If you need some dummy data to show before the backend team is ready, this is trivial. Guess I’m just not a Big enough mocking fan to ever need a library for what is such a small thing in my experience

I used Mirage with Ember for many years and it has changed the way I think and approach front-end acceptance testing. I was very excited to see the work to extract the Ember-specific bits from the rest of the library (originally by @cowboyd &#x2F; Charles Lowell and now from the original author Sam Selikoff himself) and am using it with a React app to great success.

You beat me to this idea but I&#x27;m glad you did. Nice library. Mock API&#x27;s are quite the productivity multiplier. I use them extensively for local development, prototyping, testing, and demoing. I&#x27;ve hacked similar things for work; first one was based on jsondb and the second one was based on axios-mock-adapter.<p>Colorizing[1] the console logs for quickly parsing success and failure might be a nice addition. [1]: <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;tools&#x2F;chrome-devtools&#x2F;console&#x2F;console-write#styling_console_output_with_css" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;tools&#x2F;chrome-devtools&#x2F;cons...</a><p>edit: grammar

Been using the original Mirage project on an Ember app for years (testing and fake offline demos functionality), and now this iteration takes it over the top. I can&#x27;t recommend it enough.

I remember using Mirage back when I was an Ember developer. Everything else seemed so backwards in comparison, and honestly still does. I&#x27;m definitely interested in trying this out.

This is cool. Mockability is one reason I&#x27;ve been so heavily biased to choosing GraphQL for my backend APIs recently. GraphQL makes it super easy to (a) first define a contract between client and server, and then (b) front end teams can trivially mock this out to develop the front end while the backend team actually implements the API.<p>Glad to see something like mirage solving this across all different types of API frameworks.

This is awesome! Exactly the kind of library I’ve been looking for.<p>Does anyone have any suggestions on a way to start with an OpenAPI spec and end up with a mock data set? With Mirage it seems easy enough to mock our API directly from scratch, but if we could save a few steps and go from OpenAPI spec to mocked front end that would be bliss.

I&#x27;ve used Mirage for a bit while working on an Ember project. It was really awesome and user-friendly and easy to use.<p>I have been using <a href="https:&#x2F;&#x2F;github.com&#x2F;nock&#x2F;nock" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nock&#x2F;nock</a> in Node.js for ages and I love it as well.

At our job we used to mock both frontend and backend and we needed consistency, so to help us I developed <a href="https:&#x2F;&#x2F;mockadillo.com" rel="nofollow">https:&#x2F;&#x2F;mockadillo.com</a> which is imho easier to use than embedding mocks in your code.

Great tool! I cannot say how much I like using Mirage, and how much it helps me while developing applications. I have used it only with Ember.JS and I always missed having it while using some others JS frameworks.<p>Much appreciated Sam and much love ️

We use Mirage for a large scale ordering front-end built with Ember. It’s enabled almost zero flakiness when writing our acceptance tests; super excited to see the library get ported outside the Ember ecosystem!

Thank you! I hacked something similar quick and dirty, but i will use definitely Mirage with my next project.

I&#x27;m a bit of a noob so hang with me here.<p>So you install it as a dev dependency via npm.<p>So is it running ... with the client app as a proxy between the client application and just waiting for the API requests and taking those responding?<p>Is it possible to configure some delay in responses?

Nice tool. But apart from the great landing page, what&#x27;s the difference with FakeRest [0]?<p>0: <a href="https:&#x2F;&#x2F;github.com&#x2F;marmelab&#x2F;FakeRest" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;marmelab&#x2F;FakeRest</a>

This looks really cool. Is there a difference between this and json-server [0]?<p>0: <a href="https:&#x2F;&#x2F;github.com&#x2F;typicode&#x2F;json-server" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;typicode&#x2F;json-server</a>

Is it possible to include it as a standalone js file? Instead of using npm or yarn?

Finally a library to help me make a mockery of my project!