Mocking APIs for frontend developers

Considering how loosely coupled web development is these days, leading to a separation of the frontend (mostly SPA) and backend(API driven) of our applications and often handled by different teams, one major thing to consider is the “blocked factor.”

The blocked factor is how long a developer spends waiting on external API dependencies, hence preventing a feature development on the frontend or a project altogether.

Mocking is a way out of this blocked factor. They are easy to write, flexible, and stateless (hence testing scenarios repeatedly is easier) and ultimately provide a way out of external API dependencies.

Mocking allows us to simulate the backend API by specifying endpoints and the responses it gives.

The Mocking Framework

In this article, I would demonstrate how to use MSW (Mock Server Worker) to mock APIs for a todo react application.

Mock Service Worker is an API mocking library that uses Service Worker API to intercept actual requests. — mswjs.io

N.B: MSW is fully framework agnostic and also supports GraphQL. You should check it out!

Let’s get started!

We need to install MSW.

Next would be to set up mocks. I do separate the API actions such as create, read, e.t.c from the mock servers themselves just for convenience.

Let’s do that.

We can create our mock now.

If you are familiar with the express framework of node.js, the way to write the REST API Mock with MSW is similar.

server worker used for client-side mocking with all the rest endpoints

Above, we have defined all the REST APIs with their responses, and if you notice, our REST endpoints all point to an HTTPS server (the apiUrl prefix). This is because service workers are to be served over HTTPS and not HTTP (Always note that).

We could attach the response status, JSON, e.t.c, which is great and similar to how our APIs behave normally.

The setupWorker or the handler has not yet started; hence the Service worker API will intercept no request. We will start the worker in a development mode because we don’t want to hit a mock in production or even staging.

Let’s do that.

All we need to do is import the above file into the entry point of our application.

//index.ts
import './server'

Now, when we start our react application, we should see the following in the browser console.

Terrific!

If we make an API request to the “/todo/all” endpoint and look at the Network tab, we will see an actual request and the corresponding response served by the service worker API.

Request to retrieve all todos in our todoDB.json and response served from the service worker API

And we will retrieve the todos data from our todoDB.json.

Response from the todoDB.json

This is great as we don’t have our backend ready and much more; we are not experiencing any blockage in our development process as frontend developers.

One of the major concerns regarding using mocks is maintenance, as the backend behavior might change rapidly, and we have to maintain the mocks. This is a valid point, but if we are to write tests (we will do in the second part of this article) for this APIs consumptions on the frontend, we would still need to maintain our mocks considering that our users won’t mock fetch or Axios hence our test shouldn’t as well, what if there is a way to share the handlers between the dev server and the test server hence maintaining just one handler and API actions.

We will explore the power of MSW much more in the next article.

Thank you for reading.