Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments. 

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

graphql

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Node.js

Controlling the network is the key to fast prototyping, bullet-proof tests, and efficient debugging. In this course, you will learn how to use Mock Service Worker for API mocking—from the setup and your first request handler to describing more complex network scenarios, such as dynamic requests, HTTP streams, and schema-first GraphQL mocking.

Kamil Khadeyev

Hi! My name is [Artem](https://kettanaito.com). In this course, I will teach you how to mock REST and GraphQL APIs with [Mock Service Worker](https://mswjs.io). Together, we will build a movie streaming application and you will learn how to intercept both server-side and client-side requests and mock responses using standard JavaScript API. This is a state-of-the-art mock-first prototyping with MSW.

- Join my [Discord server](https://kettanaito.com/discord) to go through the course with others, ask questions, and share feedback. See you there!

Introduction to Mock REST and GraphQL APIs with Mock Service Worker

Before we begin, let's see how you can clone the Movie App repository from GitHub. This is not mandatory but will be helpful if you decide to follow along as we go through each lesson.

- [Movie App on GitHub](https://github.com/kettanaito/movie-app)

javascript

Clone the GitHub Repository for Mock REST and GraphQL APIs with Mock Service Worker

Let's add `msw` to the project and prepare the basic directory structure with our `handlers.ts` where you will describe the network behavior you want. 

Install Mock Service Worker (MSW) and Prepare Directory Structure

As the name implies, Mock Service Worker (MSW) uses the Service Worker API to intercept requests in the browser. By doing that, it can achieve API mocking without patching "fetch" or affecting the source code of your app in any way—all by using the platform. Learn how to copy the worker script and register the service worker to have API mocking enabled in for client-side development.

- [Browser integration](https://mswjs.io/docs/integrations/browser)

Set Up MSW in the Browser

Let's use the "setupServer" API from Mock Service Worker to enable API mocking on the server-side of our Remix application. This way you can intercept and mock server-side requests, like those happening in the "loader" and "action" functions, as well as reuse the same setup for any other Node.js process, like integration tests with tools like Vitest or Jest in the future.

- [Node.js integration](https://mswjs.io/docs/integrations/node)

Set Up MSW in Node.js

To control what happens to requests in Mock Service Worker, you need to intercept them first. Write your first **request handler** and learn how to intercept a server-side request our application makes in Remix's `loader`. And mocking a response? Using a Fetch API `Response` instance, of course!

- [Describing RESTful APIs](http://mswjs.io/docs/network-behavior/rest)

Intercept and Mock Server-Side HTTP Requests in MSW

Mock Service Worker relies heavily on the standard Fetch API classes like Request and Response when describing the network. But sometimes standards aren't enough. For example, you cannot mock a response cookie because JavaScript prohibits setting the "Set-Cookie" header on a Response instance. Learn how to side-step this limitation by using a new "HttpResponse" class from MSW. 

- [`HttpResponse` API](https://mswjs.io/docs/api/http-response)

Use the HttpResponse Class in MSW

When mocking a collection of resources in Mock Service Worker, such as our movies, you will encounter requests that have dynamic parts in their URL, like `/movies/:slug`. In this lesson, learn how to use _path parameters_ to describe dynamic portions of the request's URL, access those parameters, and return a different response based on their values.

- [Path parameters](https://mswjs.io/docs/network-behavior/rest#reading-path-parameters)

Handle Dynamic Requests with Path Parameters in MSW

As you add more request handlers in Mock Service Worker, introducing a source of truth for the static data can help reduce the clutter and keep the network description focus on behavior instead of repeating fixtures. In this lesson, we will refactor our code by moving the static data outside and reusing it across existing request handlers.

Add a Single Source of Truth for Fixtures in MSW

Request handlers you write in Mock Service Worker apply for both Node.js and the browser simultaneously. In this lesson, you will handle a client-side request for movie recommendations using the same `http` namespace you already know. We will also take a sneak peek at the browser's Network to see what happens to the requests when we mock them. 

Intercept and Mock Client-Side HTTP Requests in MSW

Learn how to use the native `URL` and `URLSearchParams` classes to parse the intercepted request's URL and access its query parameters inside your Mock Service Worker handlers.

- [Reading and writing request query parameters](https://mswjs.io/docs/recipes/query-parameters)

Read Request Query Parameters in MSW

Error handling is crucial for a great user experience. Learn how to reproduce _any_ error response with Mock Service Worker, be it a 404, 500, or any other HTTP error response. 

- [Mocking error responses](https://mswjs.io/docs/basics/mocking-responses#mocking-error-responses)

Mock Error Responses in MSW

Accounting for network errors is what makes a good application great. Unlike error responses, network errors represent issues when sending a request or receiving a response, but all the same can be mocked with standard JavaScript API. 

In this lesson, you will learn about `Response.error()` and how to use it to emulate network errors in your Mock Service Worker handlers. 

- [Network errors](http://mswjs.io/docs/basics/mocking-responses#mocking-network-errors)

Emulate Network Errors in MSW

The more your request handlers resemble the actual production behavior, the more confident you'll get when prototyping and testing with Mock Service Worker. But here's the thing—mocked responses arrive to the client **really quickly**. Learn how to control response timing and server-side latency by using the "delay" function.

- [`delay()` API](https://mswjs.io/docs/api/delay)

Control Response Timing in MSW

Mocking authentication comes down to how it's implemented. With Mock Service Worker, you can mock the "Set-Cookie" response header to emulate a user session, but with Remix you don't even have to. Instead, in this lesson we will intercept only the authorization call to a database, leaving Remix to handle sessions, cookies, and auth state for us. 

Use MSW to Mock Authentication in Remix

Let's spice things up by adding GraphQL to our application. 

Since you are prototyping mock-first, you don't have to write any GraphQL schemas or define any resolvers. Instead, you will utilize Mock Service Worker to intercept valid GraphQL queries by their _type_ and _name_, and respond with the same semantic JSON responses matching the queries.

- [Describing GraphQL APIs](http://mswjs.io/docs/network-behavior/graphql)

Intercept and Mock GraphQL Queries in MSW

In this lesson, you will use the Mock Service Worker `graphql.mutation()` request handler to allow the users to leave reviews for the movie they've watched. 

- [`graphql` namespace](http://mswjs.io/docs/api/graphql)

Intercept and Mock GraphQL Mutations in MSW

Error responses in GraphQL are a bit unique. They must still produce a "200 OK" response and list the errors in the response body instead. Let's follow the GraphQL specification to produce a valid GraphQL error response in our Mock Service Worker handlers. 

Mock GraphQL Errors in MSW

Operation-based GraphQL mocking allows you to move fast without investing time into schemas or resolvers. 

But, when integrating Mock Service Worker into an existing application, going schema-first can be advantageous. Here's how you can route every GraphQL request to be resolved against a GraphQL schema, mocked or real, and use mock resolvers to control individual types and fields. 

Resolve GraphQL Requests Against a Mock Schema in MSW

Let's improve our schema-first GraphQL mocks by intercepting _all_ GraphQL operations—both queries and mutations—using a single Mock Service Worker `graphql.operation()` request handler. 

- [`graphql.operation()`](https://mswjs.io/docs/api/graphql#graphloperationresolver)

Mock All GraphQL Operations in MSW

When your application communicates with multiple GraphQL services, it becomes problematic to distinguish them by operation type and name alone. Learn how to take the service's endpoint into account when intercepting GraphQL queries and mutations with Mock Service Worker.

- [`graphql.link()`](https://mswjs.io/docs/api/graphql#graphqllinkurl)

Endpoint-Based GraphQL Mocking in MSW

Mocking responses is great but what if you want to observe requests without affecting them? In this lesson, we will learn how to instruct Mock Service Worker to perform intercepted requests as-is.

- [`passthrough()`](https://mswjs.io/docs/api/passthrough)

Perform Intercepted Requests As-Is in MSW

When working with existing APIs, especially those you don't own, being able to take the original response and manipulate it can be a life-changer when iterating on features or reproducing bugs. In this lesson, you will learn to perform the original request and then use Mock Service Worker to patch it with whichever data you want.

- [`bypass()`](https://mswjs.io/docs/recipes/response-patching)

Combine Original and Mocked Responses in MSW

You can send any data from your response resolvers. Let's implement a video streaming functionality by responding with a `ReadableStream` with Mock Service Worker. As a cherry on top, you will learn how to transform that video stream to inject server-side latency and see how our application's player handles it.

Respond With a ReadableStream in MSW

Through exploration and comparison, you'll come away with actionable knowledge for designing and extending schemas.

Designing GraphQL Schemas

Build a blazing fast chat app with Remix and Supabase! This course covers everything you need, from database hosting to authentication and authorization, all with real-time updates

Build a Realtime Chat App with Remix and Supabase

Build a Node.js REST API with LoopBack

node

Mock REST and GraphQL APIs with Mock Service Worker

https://app.egghead.io/api/v1/lessons/javascript-introduction-to-mock-rest-and-graphql-apis-with-mock-service-worker/subtitles

Instructor: [0:00] Hi. My name is Artem. I'm super excited to be your instructor at Egghead and teach you how to mock REST and GraphQL APIs with Mock Service Worker.

[0:08] Historically, API mocking has gathered the stigma of being hacky, dirty if you would, but you will learn firsthand how that's not the case anymore. In fact, together we're going to build an entire application against a mock network that spawns zero servers and requires no changes to the actual source code.

[0:24] It's not going to be a simple to-do app either. We will build a movie streaming application that communicates with both REST and GraphQL APIs, third party and local, and you will learn how to intercept those requests and mock the responses using the standard JavaScript API.

[0:38] Now, I designed this course to be beginner-friendly, so don't worry if you've never used MSW or other API mocking solutions before. It's the perfect place for you to start if you haven't, but even if you've been using MSW for some time now, I still highly recommend you watch this course because it's going to show you how to use the new version of the library. I know you're going to love it.

[0:56] I worked really hard on these lessons, and it's the most complete introduction to MSW ever. I can't wait for you to discover that for yourself, and see you in the first lesson.

https://app.egghead.io/api/v1/lessons/javascript-introduction-to-mock-rest-and-graphql-apis-with-mock-service-worker/transcript

https://app.egghead.io/api/v1/lessons/node-js-clone-the-github-repository-for-mock-rest-and-graphql-apis-with-mock-service-worker/subtitles

Instructor: [0:00] You can find the source code of the application we're building on GitHub if you go to kettanaito/movie-app. Feel free to clone this repository and follow along as we go through each lesson, or if you would like to jump straight to the complete final state of the course, check out the completed branch in Git.

https://app.egghead.io/api/v1/lessons/node-js-clone-the-github-repository-for-mock-rest-and-graphql-apis-with-mock-service-worker/transcript

https://app.egghead.io/api/v1/lessons/node-js-install-mock-service-worker-msw-and-prepare-directory-structure/subtitles

Lecturer: [0:00] Open the terminal and type npm install msw to add MSW as a dependency to the project. Next, go to the app directory and create a new directory called mocks.

[0:13] In there, create a new handlers module where we will describe the mocks we want. For now, simply export a variable called handlers that equals an empty array.

https://app.egghead.io/api/v1/lessons/node-js-install-mock-service-worker-msw-and-prepare-directory-structure/transcript

https://app.egghead.io/api/v1/lessons/node-js-set-up-msw-in-the-browser/subtitles

Lecturer: [0:04] In the browser, MSW works by registering a service worker that allows it to intercept and modify outgoing network traffic. Let's create a browser module, where we will describe the browser integration.

[0:19] In the browser module, import setupWorker from msw/browser. Create a new worker variable and assign it the result of the setupWorker function call. The setupWorker function will return an object that we can use to start, stop, and control MSW execution in the browser.

[0:36] Let's export the worker object so we can reuse it anytime we need API mocking in a browser process, which can be during development or testing with tools like Playwright or Cypress. To the setupWorker call, we need to provide request handlers, functions that describe how to handle outgoing requests.

[0:51] Let's import the handlers list from the handlers module we've created before, and spread this list in the argument to the setupWorker function.

[0:57] Any service worker registration consists of two parts. It's the JavaScript API that registers the worker and the worker script itself. Our API is ready. To get the worker script, open the terminal and type npx msw. This references the MSW executable installed with the MSW package.

[1:16] On this CLI, type the init command. This command will copy the library's worker script into any directory we specify. For JavaScript to register a service worker, it has to be served from our application. It means that the directory for the worker script must be the public directory of our app.

[1:40] In Remix, that's a root-level directory called public. If unsure, check your framework's documentation to see where its public directory is located. Once the init command has finished, we can see the confirmation message about the worker script. If we go to the public directory of our project, we can see the mockServiceWorker.js file being copied there.

[1:57] Our browser integration is complete, but it won't enable API mocking just yet. To do that, let's go to the client entry of our application, which in Remix is the app/entry.client module. Here, declare a new asynchronous function called enableAPIMocking and import the worker object from the browser module we've just created.

[2:25] To register the service worker, call worker.start method. Bear in mind that registering the worker is an asynchronous action, which is indicated by the worker start method returning a promise. Make sure to await that promise before continuing.

[2:43] We also don't want any API mocking in production, so we will check the current process node environment and do an early return if this function runs anywhere except the development environment.

[2:54] Finally, call the enableAPIMocking function and move the code that renders our application in the callback when this promise resolves. This way, we defer application rendering until MSW is ready to handle requests, which eliminates race conditions between the worker registration and any requests our app makes on initial load.

[3:15] If we go to the browser's console, we can see a message saying that MSW has been successfully enabled. If we go to the applications tab in the dev tools, we can find the service worker we registered to be active and running.

https://app.egghead.io/api/v1/lessons/node-js-set-up-msw-in-the-browser/transcript

https://app.egghead.io/api/v1/lessons/node-js-set-up-msw-in-node-js/subtitles

Instructor: [0:00] There are no service workers in Node.js, but we can use MSW there all the same. Let's create a new node module where we will set up MSW in Node.js. In the node module, import { setupServer } from 'msw/node'. Create a new server variable, and assign it the result of the setupServer function call.

[0:19] The setupServer function will return an object that we can use to start, stop, and control MSW in Node.js. Let's export the server object so we can reuse it in any Node.js process, such as our development server in Remix or integration tests with tools like Vitest or Jest.

[0:36] Similar to the setupWorker function, the setupServer expects request handlers. Let's import them from the same handlers module. By relying on the same list of handlers, we introduce a single source of truth for our network description and then utilize functions like setupServer and setupWorker to let MSW establish API mocking correctly in different environments for us.

[0:57] The Node.js setup is ready. All we'll have to do is start it. To do that, go to the server entry of our application. In Remix, that's an entry.server module. Import the server object from the Node.js integration we've just created. Then, call server.listen() to enable API mocking.

[1:19] Notice that this method is synchronous, and it will affect the current process as soon as it's called. Despite the name, the setupServer API does not create any actual servers, and instead, extends the standard Node.js APIs like HTTP to provision request interception.

[1:36] As the last thing, let's make sure that we enable API mocking only while in development by checking the node environment variable on the process and calling server.listen() conditionally.

https://app.egghead.io/api/v1/lessons/node-js-set-up-msw-in-node-js/transcript

https://app.egghead.io/api/v1/lessons/node-js-intercept-and-mock-server-side-http-requests-in-msw/subtitles

Instructor: [0:00] On our home page, we have a loader function that tells Remix to make a server-side request to fetch the list of featured movies, but when we go to that page, we can see a request error because we're trying to make a request against the API that doesn't exist. Let's change that with MSW.

[0:15] Go to the handlers module and import { http } from 'msw'. We will use the http object to intercept http requests. Then in the list of handlers, type http, and take a look at the methods on this object. They represent http request methods. We will choose get because we're making a get request on the server, and call that method.

[0:37] As the first argument, we need to provide the request URL we wish to intercept. I will copy it directly from the remix loader. Then as the second argument, provide a callback function that will be called whenever this request happens. For now, let's print a console message in reaction to this request.

[0:55] We have just written a request handler. It's a function that controls the network and consists of two parts, a predicate that describes which requests to intercept, and a response resolver, a function that tells MSW how to handle this request.

[1:10] Let's verify that our request handler is working. Since the request we want to intercept happens on the server, we should be looking for this console message in the server logs in our Terminal.

[1:20] Once we refresh the page, we can see the Remix server printing our message, but the FetchError still remains because we haven't handled this request in any way just yet. To respond to an intercepted request, return a new Fetch API response instance from the Response resolver.

[1:37] In this case, our application expects a JSON response with the list of movies. I'm going to copy them right there, and I'm going to provide a Content-Type response header to specify that we're returning a JSON response. Save the changes, and refresh the page.

[1:55] What happens now is that our server makes a request, and MSW intercepts it and tries to find any matching request handlers for it. When it does, it executes the Response resolver function and uses any response it returns as the actual response our application receives.

https://app.egghead.io/api/v1/lessons/node-js-intercept-and-mock-server-side-http-requests-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-use-the-httpresponse-class-in-msw/subtitles

Lecturer: [0:05] Go to the handlers file and input an HTTP response class from MSW. We will use this class to replace the native responses in our request handlers.

[0:10] The HTTP response class is a drop-in replacement for the Fetch API response. In fact, it extends it to always remain fully compatible. I recommend using the HTTP response class instead of the native response in your handlers.

[0:24] It provides extra capabilities to describe the network that would otherwise be unevaluable, like mocking the Set-Cookie response header which cannot be set on a regular response instance. Additionally, HTTP response comes with a set of built-in static methods to help define different mock responses.

[0:41] We will rewrite this JSON response using the JSON method on the HTTP response class. Notice that this is a static method, so we don't need the new keyword anymore.

[0:52] We can then drop converting the response body to a string because the JSON method will handle it for us and remove the Content-Type and Content-Length headers because they will be set automatically based on the JSON body that we provide.

https://app.egghead.io/api/v1/lessons/node-js-use-the-httpresponse-class-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-handle-dynamic-requests-with-path-parameters-in-msw/subtitles

Lecturer: [0:00] Our application makes a GET request to fetch movie details and provides the slug of the movie we want to fetch as a dynamic part of that request URL. In other words, we don't know the exact URL until we fetch a particular movie. Let's create a handler for this dynamic request using HTTP GET.

[0:19] We will provide the static portion of the request URL and replace the dynamic parts with path parameters. A path parameter is a part of the request path that doesn't get interpreted literally, instead, it acts as an expression that takes whichever actual string will be present at this position and stores it under the parameter named slug.

[0:41] You may be familiar with path parameters if you worked on backend applications in the past. This is no different. We access the actual value of this parameter in the argument to the responseResolver function. Let's spread that object argument and get the key named params from it.

[0:57] Params is an object that holds all found path parameters, where its keys represent parameter names, like the slug we have over here, and its values equal to those parameters' values.

[1:09] The slug parameter will be different for every movie our application tries to fetch. We can check the individual movie slugs and return different responses for different movies. We will reuse the same static data from the featuredMovies handler we wrote before to stay consistent.

[1:40] To keep our network description robust, we will return a not-found response for any other slug by constructing an HTTP response instance and setting its status to 404. Once we save the changes, we can see that our application displays the correct details depending on the movie we click on.

https://app.egghead.io/api/v1/lessons/node-js-handle-dynamic-requests-with-path-parameters-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-add-a-single-source-of-truth-for-fixtures-in-msw/subtitles

Lecturer: [0:00] Let's structure our mock data a little better by storing the list of all movies in a new variable called movies. Put it on the root level of the handlers module so any request handler would always have access to it. You can think of this variable as a mock database we will use during development.

[0:18] Next, let's update the featuredMovies handler to return the entire collection of movies, instead of a hard-coded JSON. In the movieDetail handler, we can drop these manual checks for the movie slug. Instead, let's use the find method on the movies array to look up any movie by the given slug path parameter.

[0:41] This makes our handler much more versatile, as it will now return any existing movie as long as it's present in the movies collection. By moving the static data outside of your request handlers, you allow them to focus on the actual network logic they describe, and also make them much easier to read and change and change.

https://app.egghead.io/api/v1/lessons/node-js-add-a-single-source-of-truth-for-fixtures-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-intercept-and-mock-client-side-http-requests-in-msw/subtitles

Lecturer: [0:00] let's render a list of recommended movies for each movie we are browsing. Since it's non-blocking information, we will perform this request on the client. In this case, it's a GET request to the api/recommendations root we've defined in Remix.

[0:16] We don't know how this route will be implemented just yet, but that doesn't stop us from developing and testing this UI. In our handlers module, let's add a new request handler for the recommendations endpoint.

[0:34] Notice that we don't have to provide the absolute request URL because this endpoint is served by our application. We can drop the application's host altogether and let MSW resolve the relative URL against the current location automatically. As a response, let's send back the first two movies we have in our movies collection.

[0:55] Pay attention to how we don't mention the environment or even the request client when defining our handlers. None of that is relevant because the network description should remain consistent no matter how or where a request is being sent.

[1:11] Save the changes and see the bottom of this page shining with recommended movies. Take a look at the network tab. Although we are clearly receiving the mock data right now, we can still see the actual request being sent, observe its properties, and check the response as we would do with a regular request because when using MSW, it remains a regular request.

[1:33] It gets intercepted on the network level using the service worker we registered earlier, which is indicated next to the response status code. This means our application actually performs the request as it would in production, and receives an actual response as if there is no mocking involved...

https://app.egghead.io/api/v1/lessons/node-js-intercept-and-mock-client-side-http-requests-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-read-request-query-parameters-in-msw/subtitles

Lecturer: [0:05] Let's iterate on the movie recommendations so they exclude the movie we are currently browsing. First, in the source code, we will change the request URL for the recommended movies to include a query parameter named movieID. As its value, we will provide the ID of the current movie. This way we are letting the server know that we expect the recommendations for this particular movie.

[0:27] Next, let's reflect this change in the request handler. Although our request now has a query parameter in its URL, we should not put it in the request handler predicate. Remember that our handlers describe the server behavior. For the server, query parameters don't act as resource identifiers, instead, they represent additional data sent with the request, similar to the request body in that regard.

[0:45] To access query parameters, first, get the request reference from the resolver argument. The URL property on the request instance contains the resolved request URL including query parameters, represented as a plain string. Working with it in its raw form is inefficient, instead, let's construct a URL instance based on the request URL string.

[1:08] The URL class is a native JavaScript API that will parse the given URL and give us a handy interface to work with. To get the value of the movieID query parameter, we will type URL.searchParams.get and provide the parameter name movieID. The searchParams property on the URL instance represents parsed query parameters, and its get method returns the value of a parameter by its name.

[1:39] Knowing the exact movie ID, let's now filter it out from the list of recommended movies and update the mock response.

[1:50] Our recommendations handler now matches the behavior we would expect from the production API much more closely.

https://app.egghead.io/api/v1/lessons/node-js-read-request-query-parameters-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-mock-error-responses-in-msw/subtitles

Instructor: [0:05] When working on the UI that fetches data, we have to account for different network-related states such as error responses, latency, and connectivity issues. In our movie recommendations component, we want to display a user-friendly error message whenever fetching the recommendations fails. With MSW, we can reproduce any network state using request handlers.

[0:22] To respond to a request with an error, construct a valid response instance, and set its status property to reflect the server error you want. In our case, let's see how our UI handles a response with a 500 status code, which indicates a generic server error when handling this request.

[0:40] We've got our request handler pinned to always return an error response, which is handy while working on error handling in our application. Same as with successful responses, we can see this 500 response in the Network tab, in the browser's DevTools. To toggle between the success and error responses, we can return our 500 response conditionally.

[1:00] As an example, let's respond with an error only when fetching recommendations for a particular movie. With this condition in place, we can now check different states of the UI by opening different movies in the browser.

[1:13] You can utilize error responses to help you develop features or catch issues. For example, it's a good idea to check if the movieId query parameter has been sent by the client, and if it's missing, respond with a 400 response indicating a bad request and a JSON body describing what's wrong.

https://app.egghead.io/api/v1/lessons/node-js-mock-error-responses-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-emulate-network-errors-in-msw/subtitles

Instructor: [0:00] Being able to model any server response is powerful, but there is a whole area of network issues that are not caused by the server. What if the client loses the Internet connection, or the network provider fails to resolve the DNS record for the host or app requests? Depending on the product you're building, these network errors can have a different impact on your users.

[0:19] I still recommend accounting for them, at least to some degree, to build bulletproof UIs. The best part is that we can use the standard JavaScript API to reproduce network errors. To create a network error response, call the error static method on the Response class. Since HTTP response extends the standard response class, it also inherits the error static method.

[0:45] Note that network errors and server errors are quite different. A server error still represents a complete response from the server, only indicates a semantic problem while handling the request. This is the reason why the Fetch API doesn't reject the request promise when you get 400 or 500 responses.

[1:03] A network error, on the other hand, means a failed request, the kind that was aborted during processing, or that has never reached the server to begin with. As a result, network errors reject the pending request promise. Keep this difference in mind when handling these two kinds of errors.

https://app.egghead.io/api/v1/lessons/node-js-emulate-network-errors-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-control-response-timing-in-msw/subtitles

Instructor: [0:00] You might have noticed that developing against a fixed network description is really fast. In fact, our application receives responses almost instantaneously, which is great while iterating on a feature, but it's likely to be different once it starts communicating with an actual production API.

[0:16] We can affect the server response timing in any request handler using the delay() function from MSW. The delay() function returns a timeout promise that we can await in any point in our resolver by making it an asynchronous function.

[0:30] When called without any arguments, the delay() function will create a timeout with a random duration that emulates an average server response time. We can provide an exact delay duration in milliseconds as well. This is handy when working on logic that depends on the server response time, like handling request timeouts on the client, for example.

[0:54] The delay() function can also accept a delay mode. A delay mode is a special string that tells MSW how to delay this response. We can use the real delay mode to emulate an average server response time. It's the same as using delay without any arguments.

[1:14] There is also an infinite delay mode, which causes the request to pan forever, allowing us to develop and test the loading state of our application or its individual components.

[1:23] Since our request handlers are environment-agnostic, the delay can affect the response time for both client-side and server-side requests.

[1:34] For example, if we add a delay to the featured movie's handler, it will affect the initial page load time because that request happens on the server.

https://app.egghead.io/api/v1/lessons/node-js-control-response-timing-in-msw/transcript

https://app.egghead.io/api/v1/lessons/remix-use-msw-to-mock-authentication-in-remix/subtitles

Lecturer: [0:04] Describing authentication will largely depend on the way you decide to implement it and will vary from simple JSON responses to mocking the entire request flow, auth tokens, and response cookies. No matter the approach, you can always represent it with MSW.

[0:15] In our application, we have a signing route that renders the authentication form on the client and has a server action to handle form submissions. We will follow Remix's best practices and create, store, and invalidate the user session using cookies. Let's take a closer look at this authentication flow.

[0:32] First, we get the credentials that the user submitted as the requests form data, then we forward them to a third-party endpoint for validation. You can think of this request as a call to the auth provider or a direct REST API call to your database to see if the user exists. If it does, we take the user object returned from the validation response and set it on our session.

[1:00] After we've handled errors, we set the session cookie on the response and finish the flow. In a setup like this, controlling authentication comes down to controlling the validation request, so let's do that with MSW. In our handlers, create a new HTTP post handler for the validation endpoint.

[1:16] We are forwarding the request's form data body from the Remix action to this request so we can get the submitted user credentials by reading the intercepted request body as request.formData. Let's grab the user's email and password using the form data's GET method. Next, add the basic input validation to respond with a 400 response if any of the credentials are missing.

[1:49] Finally, send a response to indicate a successful authentication. This response will depend on what the client expects from this endpoint, which in our case is the user object.

[2:00] Now, the validation endpoint will always return this user object and proceed to store it in the cookies, creating a new session once we sign in with any credentials. Since the sign-out route invalidates any present session cookies using Remix, we get the sign-out functionality out of the box, no handlers necessary.

https://app.egghead.io/api/v1/lessons/remix-use-msw-to-mock-authentication-in-remix/transcript

https://app.egghead.io/api/v1/lessons/graphql-intercept-and-mock-graphql-queries-in-msw/subtitles

Instructor: [0:00] On the Movie Detail page, let's fetch a list of reviews for this movie using GraphQL. Although GraphQL requests on the web still use HTTP, I recommend using a designated GraphQL client like Apollo, URQL, or GraphQL request instead of plain fetch calls.

[0:16] This way, our prototypes stay specification-compliant from day one, and the code we write is the same code we would ship to production. In the reviews list component, we are sending a GraphQL query called listReviews that will fetch the list of reviews by the given movie ID.

[0:33] Each review will have the id, text, rating, and author fields in the response. This query definition is all we need to handle it with MSW. In our handlers, import the GraphQL object from MSW. We will use this object to describe GraphQL APIs.

[0:50] The way you model your GraphQL will be based on the queries and mutations that you're sending from the client, so I will copy the movieReviews query and put it next to the request handler for reference.

[1:07] To intercept a GraphQL request, we will type GraphQL and choose the right operation type from the methods on the subject. We want to intercept a query, so we will choose the GraphQL.query method.

[1:20] As the first argument to it, provide the query name, which in our case is listReviews. The second argument will be the response resolver function, the same as with the HTTP handlers.

[1:32] Our query sends a movieId variable to fetch the reviews for that particular movie. To access the variables of a GraphQL operation, use the variables key on the resolver argument.

[1:44] Variables is a plain object whose keys equal the variable names from the query definition, like movieId, and values equal to those variables' values. Knowing the right movieId, let's look it up in the list of all movies.

[2:02] Once we've got the movie, get its reviews property that will represent the list of all reviews this movie has. We will add the actual data later. GraphQL servers must return JSON responses, so let's return one using the httpResponse.json static method.

[2:22] GraphQL responses have a set of differences compared to regular HTTP responses. They must always return a 200 status code, even in case of errors, and their JSON body is restricted to the root-level data, errors, and extensions properties. We must respect these differences to produce valid GraphQL responses so that the client would handle them properly.

[2:44] To respond with data, add the data property on the response body. The shape of the data you return from GraphQL handlers should correspond to the fields described in the query. This means we will have the Reviews property that points to the list of movie reviews. Let's follow the structure of the Review fields and add a review to the existing movie.

[3:22] Now, when our application does a GraphQL request, MSW intercepts it and tries to find any matching GraphQL request handlers for its operation type and name. Once it does, it uses whichever response we return from the response resolver as the actual response our application receives.

[3:41] Notice that we haven't defined any types, schemas, or resolvers yet. MSW allows us to experiment with different APIs, both REST and GraphQL, without fully committing to either ecosystem while still writing production-ready code.

https://app.egghead.io/api/v1/lessons/graphql-intercept-and-mock-graphql-queries-in-msw/transcript

https://app.egghead.io/api/v1/lessons/graphql-intercept-and-mock-graphql-mutations-in-msw/subtitles

Lecturer: [0:00] To let our users leave reviews for their favorite movies, we have a createReview form on the client and the remix action on the server to handle its submissions.

[0:09] The review itself is created by performing a GraphQL mutation called addReview. It has two variables, the author who submits the review and the review itself, and it sends back a review object with the ID and text to the client to display the review in the UI.

[0:25] We will follow the shape of this mutation and create a request handler for it. In our handlers, we will call graphQL.mutation method to intercept a GraphQL mutation. Same as with queries, the first argument to the GraphQL mutation method will be the operation name, addReview.

[0:42] In the response resolver, access the mutation variables and get the author and the review input data sent from the client. Using the movieId property on the review input, let's find that movie from the collection of all movies by its ID.

[1:04] Next, let's construct the new review object by taking the review sent by the user and adding the missing fields to complete it. Keep in mind that the data structures you describe will depend on your particular use case. We will check the existing movie reviews and add a new review to that list.

[1:28] Finally, respond with a JSON response whose data follows the structure of our mutation. With this request handler in place, we can go to any movie we want and submit a new review for it just as our users would.

https://app.egghead.io/api/v1/lessons/graphql-intercept-and-mock-graphql-mutations-in-msw/transcript

https://app.egghead.io/api/v1/lessons/graphql-mock-graphql-errors-in-msw/subtitles

Lecturer: [0:06] When adding a new movie review, the movie ID sent from the client may point to a movie that doesn't exist. To guard against situations like this, let's return a meaningful error message if that happens.

[0:12] To respond with a GraphQL error, return a valid JSON response with the root-level error's property. According to the GraphQL's specification, the error's property must contain a list of all errors that occurred while handling this operation, both entire request errors and field-related errors, if we still want to return partial data in the response.

[0:32] In our case, let's create a single error with the message saying that a movie by the given movie ID cannot be found.

https://app.egghead.io/api/v1/lessons/graphql-mock-graphql-errors-in-msw/transcript

https://app.egghead.io/api/v1/lessons/graphql-resolve-graphql-requests-against-a-mock-schema-in-msw/subtitles

Tutor: [0:00] MSW allows us to control the network on a simple request-response basis. This means that it will use the exact responses we return without any transformations unless we explicitly define them.

[0:12] In the case of GraphQL responses, the client will receive any JSON we send back, even if it contains the fields that the original query didn't request.

[0:20] On one hand, this means we can start with GraphQL instantly without having to define any schemas or resolvers. On the other, we don't get the fields filtering that we expect from an actual GraphQL server. To make our GraphQL handlers behave as the actual production server, we can resolve the intercepted queries against the GraphQL schema.

[0:39] First, let's import the GraphQL and buildSchema functions from the GraphQL package, which is the official implementation for GraphQL in JavaScript. To prevent a namespace collision, import GraphQL as executeGraphQL.

[0:54] Next, let's define our GraphQL schema. You can use an existing schema if you have one, or create a mock schema while prototyping. Let's create a schema variable and set its value to the result of the buildSchema function call. This will transform our schema definition into an abstract syntax tree that the GraphQL package expects.

[1:13] Next, we will write a GraphQL schema that defines the types movie, review, and user, as well as the reviews query that returns the list of movie reviews, all using the GraphQL schema definition language.

[1:26] Let's adjust our existing listReviews handler to resolve against the GraphQL schema we've defined. A great thing about this is that we'll use the native GraphQL functionality to do that by calling the executeGraphQL function.

[1:39] This function needs a schema argument and the source. The source is the actual query object sent from the client. Let's get that query object as the query key on the responseResolver argument and provide it as the source.

[1:55] Forward the variables of the intercepted GraphQL query so we can access them in the resolvers later. Finally, let's add the root value that will describe the resolvers for our schema.

[2:07] Right now, we only have a single query called reviews in our schema, so let's define a GraphQL resolver for it. This is a regular resolver function in GraphQL, so we can access things like the arguments object for this field.

[2:21] In this resolver, let's paste the review logic we've had before, which consists of looking up the movie by the given movieId argument and returning the list of movie reviews if they exist. The executeGraphQL function will return a promise, so let's await it.

[2:39] This promise resolves to an object containing the errors and data properties, representing the errors and the resolved data for this query, respectively. This is precisely what we need to send back to the client, so let's return a JSON response, including the errors and data from GraphQL.

[2:57] With these changes, we are still sending the right movie reviews to the client, but instead of resolving from mock data directly, we are implying GraphQL to actually resolve the intercepted query against our mock schema.

[3:10] This gives us a lot of flexibility. For example, if we decide to drop the rating field, all we have to do is adjust the query sent from the client and see that the mock response automatically reflects that and no longer includes the removed field in the payload.

https://app.egghead.io/api/v1/lessons/graphql-resolve-graphql-requests-against-a-mock-schema-in-msw/transcript

https://app.egghead.io/api/v1/lessons/graphql-mock-all-graphql-operations-in-msw/subtitles

Lecturer: [0:00] As our application grows and starts making more GraphQL requests, it would be great to resolve them against the same schema that we have. We can of course copy and paste the executeGraphql logic across different request handlers, but that won't be a scalable approach.

[0:14] Instead, we will migrate from GraphQL query and GraphQL mutation handlers to use graphql.operation. The GraphQL operation handler will intercept all GraphQL operations regardless of their type or name, and allow us to handle them using a single responseResolver function.

[0:33] Let's move the existing executeGraphql logic from our listReviews handler to the newly added operation handler. Just like the other responseResolvers for GraphQL, we will access the query and variables arguments on the responseResolver.

[0:47] Since the GraphQL operation handler will now also intercept the addReview mutation, let's define it in our schema so that GraphQL knows about it and can resolve it. Add a new mutation called addReview with arguments author and reviewInput.

[1:07] Next, define these userInput and reviewInput types. Now that our schema understands the addReview mutation, let's add a GraphQL resolver for it in the root value object in our handler.

[1:30] We will move the logic from the addReview request handler to this GraphQL resolver. Since this resolver executes in a GraphQL context, we can't really return any HTTP responses from it, so let's replace the error response with throwing a regular error and rely on GraphQL propagating this error to the response for us.

[1:58] In the same manner, instead of returning a successful response, we will return what the addReview mutation expects, the new review object.

[2:05] Finally, let's remove the previous GraphQL request handlers because we don't need them anymore. Both our query and mutation resolve against the actual GraphQL schema now, and so will any other GraphQL requests we may add in the future, all using a single GraphQL operation request handler.

https://app.egghead.io/api/v1/lessons/graphql-mock-all-graphql-operations-in-msw/transcript

https://app.egghead.io/api/v1/lessons/graphql-endpoint-based-graphql-mocking-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-perform-intercepted-requests-as-is-in-msw/subtitles

Lecturer: [0:04] With MSW, returning mock responses from response resolvers is not mandatory. In fact, you can just observe the network traffic without affecting it in any way. All you have to do is be explicit about it. To do that, import the passThrough function from MSW. Create a request handler for the request you wish to observe or use any existing request handlers.

[0:20] As an example, let's modify the movie recommendations handler we already have. If we return the passThrough function call from this response resolver, MSW will perform this intercepted request as is. This means that the client will receive the original data.

[0:35] In our case, the data returned from the recommendationsLoader function in Remix. We can make great use of this pattern if we pass through requests conditionally. Let's return to the movie recommendations handler and pass-through this request only for a particular movie ID.

[0:57] This way, we can alternate between the mock data and the original data based on the requested resource.

https://app.egghead.io/api/v1/lessons/node-js-perform-intercepted-requests-as-is-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-combine-original-and-mocked-responses-in-msw/subtitles

Instructor: [0:00] With MSW, we can combine original and mock data in the same response using response patching. Let's create a new request handler for the featured movies endpoint that already responds with a list of actual production movies, and grab its request reference.

[0:21] Naturally, what we want to do is just fetch this intercepted request to get the original response. If we do this, this fetch call will create a new network entry for which MSW will find this matching request handler again, triggering another fetch call and resulting in an infinite loop.

[0:37] To prevent this from happening, MSW comes with a built-in API to bypass requests called bypass. Go to our fetch call and wrap the intercepted request instance in the bypass function call. This marks this request and instructs MSW to ignore any otherwise matching request handlers when it happens, which is precisely what we want to get the original response.

[0:59] The rest is regular fetch API response handling. We will await the response promise and then read its JSON body as the list of originalMovies. At this point, we can do whatever we want with the original response because it's just a plain JavaScript array.

[1:17] Let's return a new JSON response that will send back the originalMovies array, concatenated with the list of mock movies we have. With this request handler, our application receives a mix of the original data from the production API and the mock data from the request handler at the same time.

https://app.egghead.io/api/v1/lessons/node-js-combine-original-and-mocked-responses-in-msw/transcript

https://app.egghead.io/api/v1/lessons/node-js-respond-with-a-readablestream-in-msw/subtitles

Instructor: [0:04] When a user starts watching a movie, our application creates a custom media source object, fetches the actual movie stream from a third-party endpoint, and displays it to the user. We can get full control over that video stream with MSW. In our handlers, create a new request handler for the video stream endpoint.

[0:22] Let's fetch a placeholder video from an existing API. Finally, return that videoResponse as is. Since MSW operates with the standard Fetch API request and response instances, we don't have to wrap this videoResponse in the HTTPResponse provided by the library, because all we want to do is send it to the client as is.

[0:41] If we play any movie now, we will see that video stream from our request handler right in the application's player. This way we can develop and test any streaming-related logic in the UI, but we can do even more. Since we have full control over how this video stream is sent to the client, let's transform it a little.

[1:01] First, get the reference to the original readable stream of the videoResponse. Then create a new transform stream called latencyStream. We need to describe the start method for it to work correctly, and the transform method that will transform every chunk of the stream.

[1:21] As the name implies, let's add some latency to the latencyStream. We can do that by converting the transform method to be async and awaiting the delay promise from MSW before queuing each chunk of the stream.

[1:33] What's left is to respond with the modified stream. We will replace the original response with a new HTTPResponse instance from MSW. As the body of this response, take the original video stream and pipe it through the latencyStream using the pipeThrough method.

[1:48] The pipeThrough method is a standard method available on any readable stream in JavaScript. It will take the original stream and pass it through a transformation stream that will inject delay between every written chunk. Finally, forward the original videoResponse object as the second argument to our mocked response to inherit its status code and headers.

[2:08] By piping the video through the latencyStream we can see stuttering between the video chunks as it plays. This is the delay function from our latency stream creating a server-side delay.

https://app.egghead.io/api/v1/lessons/node-js-respond-with-a-readablestream-in-msw/transcript

Mock REST and GraphQL APIs with Mock Service Worker

Artem Zakharchenko

You might also like these resources:

Designing GraphQL Schemas

Build a Realtime Chat App with Remix and Supabase

Build a Node.js REST API with LoopBack

Credits

Course Content

You might also like these resources:

Designing GraphQL Schemas

Build a Realtime Chat App with Remix and Supabase

Build a Node.js REST API with LoopBack