Do you ever hear any of these statements at your workplace: I can’t. The API is down again. I’m blocked. I’m need updates to the API before I can continue. I wasn’t able to get much done. The VPN was down, and I couldn’t connect to the API. I spent half my day getting the APP into one, specific state over and over again. Shoot me. Dependence on a functioning API is a drag. It slows development down. It forces you work where you have a network connection. It can make getting your app into a specific state really difficult. And, if the API goes down, you’re hosed. You can solve all these problems by using a Mock API. A Mock API is a utility that intercepts and/or requests, and returns mock data. By introducing a Mock API to your application you will: XHR fetch never be blocked by a broken or unavailable API again. never need to wait for feature updates to your API before beginning development. You can work in parallel with the API team, once you agree on an API contract with them. make it easy for you to simulate specific states in your application. Sound awesome? It is! A Mock API in Four Steps Setting up a Mock API is super easy. Here’s how you do it: Install a and/or mock utility — what you install will depend on the needs of your app. fetch XHR Create mock data. Configure API Mocking. Configure your application to turn API mocking on and off. One bit of terminology: . A fixture is a tool that allows you to work with sample data. We’ll use the term to refer to both the Mock API, and the data it returns. Fixture fixtures The Sample App In this tutorial, we’ll take an existing application — Contact Manager — and add fixtures to mock its API. Contact Manager only uses . We’ll use , a utility for mocking http requests made using . fetch. fetchMock fetch Contact Manager uses the resource of the publicly available JSONPlaceholder API. You can see for more details. users https://jsonplaceholder.typicode.com/ You can clone the app from here: . Once you’ve cloned it, download the dependencies by running: https://github.com/joe-crick/contact-manager or yarn npm i Installation Installation of is standard: or fetchMock yarn add fetchMock -D npm i fetchMock -D : The flag saves the module as a devDependency. Note -D Create Mock Data Your mock data must match the data definition for results returned from your API. Contact Manager utilizes one resource — . The resource returns an array of objects. users users user First, we’ll create a folder called to hold both the fixture data and the API mocks. Inside that folder, we’ll create a file called . will contain a small set of user data that matches the form of the data defined by the resource: fixtures users.js users.js users Configure API Mocking Next, we’ll add a file called . This is the file where we’ll define what resources our fixtures will mock: fixtures.js There are three things required to create a simple API mock: HTTP method URI matcher Response data **HTTP method** provides mocking for all HTTP methods (GET, POST, PUT, &c.). To work with a particular method, just call it off the object — e.g., , or . fetchMock fetchMock fetchMock.get fetchMock.post also has several different ways you can match a resource URL, including: URI Matcher fetchMock string literals globs regular expressions and more… Above, I’ve used regular expressions. We imported the response data we created from . For the call to , we return all the users. For the response from a to update users, we return the first user. Response Data users.js GET users PUT Implementing a mock API gives you full control over the responses your mock API returns. This is very powerful. For example, it can help you more easily develop your application for specific cases — unique application states and errors. Specific Application States Let’s walk through an example of how to do this using an error state. In the folder, add a file called . fixtures error-fixtures.js allows you to pass in a object as its return value. By passing in a object with a 500 status, we can generate a server error. fetchMock [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) Response Now, whenever you want to test how your application will respond to an API error on user update, you can do so easily. With this setup, an error will be generated each time you try to update a user. For full details on how to work with , see its . fetchMock documentation Configure your application to turn API mocking on and off The final step in the process is configuring your application so that you can easily turn fixtures on and off. There are lots of ways to do this. We’ll take a simplified approach. Under the folder, create a file called . fixtures set-fixtures.js The code above sets a function, on the window object that allows you to easily turn fixtures on or off. relies on an item, , set in . If the item is true, we turn fixtures on, and vice versa. Finally, all of this can only happen if the environment is not production. toggleFixtures, toggleFixtures fixtures localStorage fixtures Other Options is great if your application only uses . If you need something else — or something in addition — there are other options. Here are a few: fetchMock fetch is a utility produced by the folks at Bitovi. They develop the CanJS and DoneJS frameworks. is designed to work with XHR. You can find more information here: can-fixture can-fixture https://canjs.com/doc/can-fixture.html is another utility that mocks XHR. It’s developed by James Newell. You can find more information on here: . xhr-mock xhr-mock https://www.npmjs.com/package/xhr-mock GraphQL . Mocking a GraphQL api is a bit of a different process. Read this article for more information on creating GraphQL mocks: graphql-tools https://www.apollographql.com/docs/graphql-tools/mocking.html Summary Creating a mock API for your application enables you to build UI components and features without a backend implementation. This: liberates your UI development from backend dependencies and issues. makes it easy to simulate specific situations in your application. allows you to work on and test your application offline.
