DEV Community: Bruno Henrique Gusmão Vasconcelos

Creating mock server using MSW (Mock Service Worker)

Bruno Henrique Gusmão Vasconcelos — Wed, 24 Aug 2022 08:22:00 +0000

Introduction

Mock Service Worker or just MSW, is a mocking library that uses Service Worker API to intercept actual requests.

MSW Provides two different types of mocks:

Service Worker Mocks: ideally to be used in the Browser
Server Mocks: to be used in nodejs applications

In this example we are going to use the Server Mock for a Nodejs Application and setup mocked apis for testing and for development.

I'll be using this repository as reference for all the examples in this post. So feel free to take a look, clone and do your own tests: https://github.com/brunohgv/msw-test

For more information you can check the MSW docs: https://mswjs.io/docs/

Implementation

MSW Setup

Installing

To configure MSW we fist need to install it

npm install msw

Then we need to create our basic structure to mock a server.

Creating handlers

In this example I'm going to use the https://jsonplaceholder.typicode.com/ api as reference.

To create it we just need to define some handlers. Handlers are the instructions of what to do when you find the request in the code. It's going to match the requests in the code and replace it by the ones we define here.

mocks/handlers.md

const { rest } = require('msw') // import msw
const { TODO_SUCCESS, TODO_ERROR } = require('./todoResponses') // import default responses

const handlers = [
    /*
     * How to read the handler:
     * When finding a GET request (because we are using rest.get)
     * to the "https://jsonplaceholder.typicode.com/todos"
     * replace the call by the callback function I'm passing
     */
  rest.get('https://jsonplaceholder.typicode.com/todos', async (req, res, ctx) => {
    return res(ctx.json(TODO_SUCCESS))
  })
]

module.exports = { handlers } // Export handlers

After setup the handlers we are good to create the mocked server

Creating the server

To create the server we just have to call the setupServer function from the msw/node package

mocks/server.js

const { setupServer } = require('msw/node') // import the setupServer from the msw/node package
const { handlers } = require('./handlers') // import the handlers we created

// This configures a request mocking server with the given request handlers.
const server = setupServer(...handlers)

// Export the server
module.exports = {
    server
}

After doing it we have all prepared to use our mocked server in our applcation

Using the mock server

In this application I'm using it in two diferent ways:

In the jest setup
For development

Using it in the Jest setup

Installing jest

To install jest you just have to run

npm install jest

Create Jest setup for tests

In this configuration, we are going to setup Jest to:

Initialize the server we created before the tests
To reset the handlers after each test to prevent side effects in other tests
And at the end we are going to close the server.

jest.setup.js

const { server } = require('./mocks/server.js')
// Establish API mocking before all tests.
beforeAll(() => server.listen())
// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())
// Clean up after the tests are finished.
afterAll(() => server.close())

After define the configuration we just have to call it in the Jest config.

Defining the Jest Config

To define the configuration to use the setup file we just need to add the path the the setupFilesAfterEnv property.

jest.config.js

module.exports = {
    setupFilesAfterEnv: ['./jest.setup.js']
}

And then, when we execute the tests, it's going to use our mock server instead of the original calls.

You can run npm run test to see the tests running and confirm the response is the same as the mock.

Using it for development

To mock the external requests we can use the same function we used in the jest configuration to start the mock server.

So, it is simple as adding a server.listen() in the index.js file.

const express = require("express");
const { server: mockServer } = require('../mocks/server') // importing the server and renaming it to mockServer to avoid misunderstandings
const todoServer = require("./todoServer");

mockServer.listen() // This is going to do all the work to mock the resquests

const app = express()

app.get('/todos', todoServer.getTodos)

app.listen(8080, () => {
    console.log(process.env.NODE_ENV)
    console.log('server started')
})

But we want to add for development, and not for production or other environments we might have.
So in this case we used an environment variable to identify in with environment we are.

I'm setting this in the package.json file, but it can be in a .env file or setting up manually in the terminal.

{
  ...
  "scripts": {
    "test": "jest",
    "start": "SET NODE_ENV=production&& node index.js",
    "dev": "SET NODE_ENV=development&& node index.js"
  },
  ...
}

PS: I'm using windows, that's why the command is SET NODE_ENV=environment, for linux and mac you can simply use NODE_ENV=environment

For the script npm start I'm setting the NODE_ENV variable to production

For the script npm run dev I'm setting the NODE_ENV variable to development

This variable is going to be accessible through the process.env.NODE_ENV attribute.

So now we are able to define if we are going to use the mock depending on the environment by just wrapping the mockServer.listen() in an if expression

const express = require("express");
const { server: mockServer } = require('../mocks/server') // importing the server and renaming it to mockServer to avoid misunderstandings
const todoServer = require("./todoServer");

// Just use the mocks if the NODE_ENV is set to 'development'
if(process.env.NODE_ENV === 'development') { 
    mockServer.listen()
}

const app = express()

app.get('/todos', todoServer.getTodos)

app.listen(8080, () => {
    console.log(process.env.NODE_ENV)
    console.log('server started')
})

And that's it.

By running with npm start you are going to call the service and get the real response

By running with npm run dev you are going to replace the real call to the mocked one.

Limiting Node.js API calls with express-rate-limit

Bruno Henrique Gusmão Vasconcelos — Tue, 06 Jul 2021 08:49:43 +0000

For many reasons you may need to limit your API calls: It can be to avoid extra cost in cloud, to create a free tier to use your API, to fulfill a third-party API requirement, to prevent performance issues... I believe if you are reading this post this purpose is very clear in your mind and you are just trying to figure out how to make it work. So let's focus on this.

The express-rate-limit is a simple and straight forward library that solves this problem for us. It's not the most complete one, but is a lightweight and fast way to achieve this goal. For most refined options the express-rate-limit itself already recommends other libraries such as rate-limiter-flexible express-brute and express-limiter.

Now starting

Installing packages

First of all you need a node.js project. So I created a directory and executed the command npm init -y to create a default package.json file.

Then I will install the necessary packages for this application: the express and the express-rate-limit

npm install express express-rate-limit

Setup express

To make it easier to execute I will update my package.json file and add a start script. It will let us to execute the project with the npm start command

...
  "scripts": {
    "start": "node index.js"
  },
...

Then I will create an index.js file in the root directory to be our entry point.
So I'll place the most generic express start code.

// express import
const express = require('express')
// express initialization
const app = express()

const PORT = 3000

// generic GET route that we will use for the tests
app.get('/', function (req, res) {
  return res.send('Hello World')
})

// server initialization 
app.listen(PORT, () => {
    console.log(`server started on port ${PORT}`)
})

So when we run the npm start (or node index.js if you jumped the package.json step) it should display that message indicating that the application is working:

And when accessing the localhost:3000 in the "/" route it will display the Hello World that we configured.

Adding the rate limit

Since we already added the express-rate-limit in the first step we just have to start using it.

The express-rate-limit work as a middleware, it means that we can use it in a single route, the entire app or a group of sub-routes.

For that we just need to understand how the express handles middlewares, but being very straight to the point we will use the use function from express to add a middleware or request handler in the root of our api to wrap it entirely.

If you want to understand more about the middleware usage by express you can check the express documentation.

Now let's use it:

First we need to import the express-rate-limit in our code just under the express import

// /index.js
const express = require('express')
const rateLimit = require('express-rate-limit')
// ...

Then we can configure the time box (windowMs) in milliseconds and the maximum number of requests per IP address (max)

// /index.js
const express = require('express')
const rateLimit = require('express-rate-limit')
const app = express()

const PORT = 3000

// Create the rate limit rule
const apiRequestLimiter = rateLimit({
    windowMs: 1 * 60 * 1000, // 1 minute
    max: 2 // limit each IP to 2 requests per windowMs
})

// Use the limit rule as an application middleware
app.use(apiRequestLimiter)

app.get('/', function (req, res) {
  return res.send('Hello World')
})

app.listen(PORT, () => {
    console.log(`server started on port ${PORT}`)
})

So that will be the default response, that we had before:

And when the limit is exceeded it will display a default message Too many requests, please try again later.:

And it's already working!

To change this message we have two options:

Add a "message" property inside the object passed as param for the rateLimit function

const apiRequestLimiter = rateLimit({
    windowMs: 1 * 60 * 1000, // 1 minute
    max: 2, // limit each IP to 2 requests per windowMs
    message: "Your limit exceeded"
})

Add a handler function to process the failure case:

const apiRequestLimiter = rateLimit({
    windowMs: 1 * 60 * 1000, // 1 minute
    max: 2, // limit each IP to 2 requests per windowMs
    handler: function (req, res, /*next*/) {
        return res.status(429).json({
          error: 'You sent too many requests. Please wait a while then try again'
        })
    }
})

BONUS

You can also use a function handler to start billing the consumer for the exceeded requests

const apiRequestLimiter = rateLimit({
    windowMs: 1 * 60 * 1000, // 1 minute
    max: 2, // limit each IP to 2 requests per windowMs
    handler: function (req, res, next) {
      applyFeesForConsumer()
      next()
    }
})

That way you will not block the request, just apply fees before continue.

And that's it!

Thank you

Thank you for reading this.

There are more available features and configurations in the express-rate-limit documentation it was just a simple example how we can use this library to control the API requests.

The examples and step-by-step are available in this repository branches.

I hope it helps you!

Go Functions: Pointer vs Value params

Bruno Henrique Gusmão Vasconcelos — Sat, 26 Sep 2020 21:25:39 +0000

In Golang we have the concept of pointers. It works similar to languages like C, C++ and represents the memory address where the variable value is stored.

You can see more about pointers here, since it is not the objective of this post.

From this concept, we can have functions that works with pointer params and value params.

The difference is the way we declare the function and how the variable will be handled during manipulation.

The code

To better explain the differences we will create a struct so we can manipulate its attributes inside the function, declare a variable with the struct type, and the functions. One with pointer param and a function with value param.

So, we will have the struct User containing Name and Github:

type User struct {
    Name   string
    Github string
}

And the functions responsible to change the Name attribute and print the struct values.

func changeAndLogPointer(user *User) {
    user.Name = "Bruno Vasconcelos"
    fmt.Printf("Name: %s, Github: %s\n", user.Name, user.Github)
}

func changeAndLogValue(user User) {
    user.Name = "Bruno Vasconcelos"
    fmt.Printf("Name: %s, Github: %s\n", user.Name, user.Github)
}

Note that the first one (changeAndLogPointer) receives a pointer and the second one (changeAndLogValue) a value.

So we will execute a main function that uses the pointer approach

func main() {
    user := &User{Name: "Bruno", Github: "brunohgv"}
    changeAndLogPointer(user)
    fmt.Printf("Name: %s, Github: %s\n", user.Name, user.Github)
}

The result of the execution is:

Name: Bruno Vasconcelos, Github: brunohgv
Name: Bruno Vasconcelos, Github: brunohgv

It happens because when a pointer is used, all changes are related to the memory address that the value is stored. I means that any changes to the parameter will impact the variable that was passed as param.

Now we will execute the function using a value:

func main() {
    user := &User{Name: "Bruno", Github: "brunohgv"}
    changeAndLogValue(*user)
    fmt.Printf("Name: %s, Github: %s\n", user.Name, user.Github)
}

And the result is:

Name: Bruno Vasconcelos, Github: brunohgv
Name: Bruno, Github: brunohgv

Why is this happening?
Since we are passing the value as parameter, the Go compiler will create another memory space to handle this variable internally. It means that any changes inside the function will impact in an internal variable, keeping the original one untouched.

So, what is the best approach?

Well, it depends. The pointer is a better option if you want to change the original value, than use that modified values in the future.
If your objective is to prevent changes and manipulate it only inside the function, the value is the best approach.

There are other usages for any of the approaches, but understand the basics is the best way to decide what will be the best choice for your application.