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.
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.
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:
the user calls the /subscribers endpoint in our monolithic app,
our application calls the microservice to get the necessary data,
the microservice retrieves the data from its own database,
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.
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.
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.
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.