API with NestJS #18. Exploring the idea of microservices

As our application grows, maintaining it might become more challenging. One of the approaches that we can take is to structure our app with microservices.

You can find the code for the microservice we create in this article in this repository. The rest of the code can still be found in the repository of our monolithic application.

The overview of microservices

By implementing the microservice architecture, we break down our API into smaller, independent components. Having a separate codebase, and implementing a microservice separately, can make our application more scalable. Because we implement and deploy each microservice separately, it might be easier to handle feature releases and bug fixes.

Also, embracing microservices can be a good approach when choosing the right tool for the job. Your company can manage some microservices in Java and some in Node.js, for example.

Building our application with microservices also offers more flexibility in terms of deployment and managing resources between services. It might also be easier to manage database schema migration if we have multiple smaller databases instead of a monolithic one.

All of the above benefits come with some drawbacks, too. Even though each microservice is simpler than a monolithic application, managing multiple smaller apps is challenging. When updating a microservice, we need to make sure that we won’t break other services that depend on it.

We also need to adjust to microservices when developing. Communicating between services is not free and introduces a bit of latency. It can stack up as the number of dependencies between microservices grows. Also, testing microservices might prove not to be easy.

Implementing microservices with NestJS

Fortunately, NestJS has a set of tools prepared to make working with microservices easier. In this article, we craft a simple microservice for managing email subscriptions. Using the knowledge from this series, we create a way to store a list of email subscribers.

Creating a microservice

First, we create a brand new repository for our microservice. To start things up, we use NestJS CLI.

For starters, we connect to a Postgres database with Docker in the same way as in the second part of this series.

To avoid conflicts between databases of our main app and our microservice, you might choose a different set of ports in our docker-compose this time

First, let’s create an entity so that we can store our subscribers.

Now, we can create a very straightforward service to add and list email subscribers.

Once we have the core logic ready, we can start thinking about how we expose our microservice. For that, we can create a controller.

Using the TCP layer

This time, it is not a regular controller, though. Although we could create the API with HTTP, NestJS suggests a different approach. Instead of using HTTP, NestJS has its own abstraction over the TCP transport layer for microservices.

There are many suggested ways to connect to our NestJS microservices such as gRPC, but those are a topic for separate articles.

When bootstrapping multiple NestJS applications into microservice architecture, NestJS establishes the connection before the first call for a particular microservice. It later reuses it across each subsequent call, which couldn’t always be achieved with HTTP.

Also, using TCP differently allows us to achieve event-based communication if we want. This way, the client does not wait for the response from the microservice.

The first approach suggested by NestJS is the request-response message style. It is suitable when we want to exchange messages between services. To create a message based handle, we need the @MessagePattern() decorator.

Above, our handlers listen for messages that match the provided pattern. A pattern is a plain value that can be an object or a string, for example. NestJS sends them along with the data:

• if { cmd: 'add-subscriber' }) is the pattern, the addSubscriber method is called
• if { cmd: 'get-all-subscribers' } is the pattern, the getAllSubscribers method is called

We also need to create a simple SubscribersModule, so that we can add it to our AppModule.

The last thing to do is to expose our microservice. To do that, let’s modify the default bootstrap function in the main.ts file of our service.

Above we use an instance of the ConfigService. If you want to know how to deal with environment variables with NestJS, check out the second part of this series.

Adding a microservice to an existing monolith app

There might be a case in which we didn’t design our application with microservices in mind from the beginning. In this case, we would want to connect our monolithic app to a new microservice.

To do that, let’s create a SubscribersModule inside of our monolithic NestJS application.

Above, we expect SUBSCRIBERS_SERVICE_HOST and SUBSCRIBERS_SERVICE_PORT to be provided in the .env file.

We also need a SubscribersController that communicates with our microservice.

Please note that even though we don’t need to send any data to get a list of subscribers, NestJS throws an error if we use null or undefined in subscribersService.send. Because of that, we pass an empty string here.

Above, we’ve created the following flow:

1. the user calls the  /subscribers endpoint in our monolithic app,
2. our application calls the microservice to get the necessary data,
3. the microservice retrieves the data from its own database,
4. our main application responds with the data.

In our SubscribersController, only logged-in users can list and create subscribers. Although that’s the case, we didn’t implement any authentication mechanism inside of our microservice that deals with subscribers. This is because we intend it to be a private API. We don’t want to expose it to the world, and we want only our main application to be able to communicate with it. Such a firewall should be configured at the architecture level. We will cover this topic more when creating an API Gateway for an architecture designed with microservices in mind.

If you want to know how to implement JWT-based authentication, check out the third part of this series.

Using the event-based communication

Aside from using the @MessagePattern(), we can also implement event-based communication. This is fitting for cases in which we don’t want to wait for a response. We can do so in the case of creating new subscribers.

For starters, we want our microservice to listen for events instead of messages.

Then, we need to emit the event from our monolithic app.

Even if this could be more performant, implementing the above might not be what we want in our case, though. Since we are not waiting for the response, we wouldn’t know if adding the subscriber succeeded. Even if it did, we wouldn’t receive details such as the id.

Summary

In this article, we’ve introduced the idea of microservices. This included creating a simple microservice and connecting it to an existing monolithic application. While this is a common use-case, we could also design architecture with microservices in mind from the beginning. This would include, for example, creating a dedicated API Gateway. We will cover that and other ways of communicating between services in the upcoming articles.