Server bootstrap

To get started, make sure @nestjs/microservices is installed within your project. This module provides the client, server, and accompanying utilities needed to convert a Nest.js API application into a microservices application. Finally, we will modify our blog application’s bootstrap to enable microservices.

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    app.connectMicroservice({
        transport: Transport.TCP,
        options: {
            port: 5667
        }
    });

    await app.startAllMicroservicesAsync();
    await app.listen(3001);
}

The connectMicroservice method instructs the NestApplication to setup a new NestMicroservice context. The object provides the options for setting up the NestMicroservice context. Here, we are keeping things simple and using the standard TCP transport provided with Nest.js. A call to startAllMicroservicesAsync starts up the NestMicroservice context. Be sure to do this before calling listen on the NestApplication.

Configuration

The configuration parameters passed to connectMicroservice depends on the transport we use. A transport is a combination of a client and server that work in unison to transmit microservice requests and responses between the NestApplication and NestMicroservice contexts. Nest.js comes with a number of built-in transports and provides the ability to create custom transports. The available parameters depend on the transport we use. For now, we will use the TCP transport, but will cover other transports later. The possible options for the TCP transport are:

• host: The host that is running the NestMicroservice context. The default is to assume localhost but this can be used if the NestMicroservice is running as a separate project on a different host such as a different Kubernetes pod.
• port: The port that the NestMicroservice context is listening on. The default is to assume 3000, but we will use a different port to run our NestMicroservice context.
• retryAttempts: In the context of the TCP transport, this is the number of times the server will attempt to re-establish itself after it has received a CLOSE event.
• retryDelay: Works in conjunction with retryAttempts and delays the transports retry process by a set amount of time in milliseconds.

First microservice handler

For our first microservice handler, let’s convert the UserController index method into a microservice handler. To do this, we copy the method and make a few simple modifications. Instead of annotating the method with Get, we will use MessagePattern.

@Controller()
export class UserController {

    @Get('users')
    public async index(@Res() res) {
        const users = await this.userService.findAll();
        return res.status(HttpStatus.OK).json(users);
    }

    @MessagePattern({cmd: 'users.index'})
    public async rpcIndex() {
        const users = await this.userService.findAll();
        return users;
    }
}

A message pattern provides Nest.js the means for determining which microservice handler to execute. The pattern can be a simple string or a complex object. When a new microservice message is sent, Nest.js will search through all registered microservice handlers to find the handler that matches the message pattern exactly.

The microservice method itself can perform the same business logic that a normal controller handler can to respond in almost the same manor. Unlike a normal controller handler, a microservice handler has no HTTP context. In fact, decorators like @Get, @Body, and @Req make no sense and should not be used in a microservice controller. To complete the processing of a message, a simple value, promise, or RxJS Observable can be returned from the handler.

Sending data

The previous microservice handler was very contrived. It is more likely that microservice handlers will be implemented to perform some processing on data and return some value. In a normal HTTP handler, we would use @Req or @Body to extract the data from the HTTP request’s body. Since microservice handlers have no HTTP context, they take input data as a method parameter.

@Controller()
export class UserController {
    @Client({transport: Transport.TCP, options: { port: 5667 }})
    client: ClientProxy

    @Post('users')
    public async create(@Req() req, @Res() res) {
        this.client.send({cmd: 'users.index'}, {}).subscribe({
            next: users => {
                res.status(HttpStatus.OK).json(users);
            },
            error: error => {
                res.status(HttpStatus.INTERNAL_SERVER_ERROR).json(error);
            }
        });
    }

    @MessagePattern({cmd: 'users.create'})
    public async rpcCreate(data: any) {
        if (!data || (data && Object.keys(data).length === 0)) throw new Error('Missing some information.');

        await this.userService.create(data);
    }
}

In this example, we used the @Client decorator to provide Nest.js Dependency Injection a place to inject an instance of the microservice client. The client decorator takes the same configuration object passed to connectMicroservice when bootstrapping the application. The client is how the NestApplication context communicates with the NestMicroservice context. Using the client, we modified the original @Post('users') API to offload processing of creating a new user to NestMicroservice context.

This diagram shows a simplified view of the data flow when a new user is created. The client makes a TCP connection with the microservice context and offloads the processing of the database operations. The rpcCreate method will return a successful response with some data or an exception. While the microservice message is being processed, the normal controller handler will wait for the response.

Take note that the microservice client send method returns an Observable. If you want to wait for the response from the microservice, simply subscribe to the Observable and use the response object to send the results. Alternatively, Nest.js treats Observables as first class citizens and can they can be returned from the handler. Nest.js will take care of subscribing to the Observable. Keep in mind, you lose a little control over the response status code and body. However, you can regain some of that control with exceptions and exception filters.

Exception filters

Exception filters provide a means to transform exceptions thrown from microservice handlers into meaningful objects. For example, our rpcCreate method currently throws an error with a string but what happens when the UserService throws an error or possibly the ORM. This method could throw a number of different errors and the only means that calling method knows what happened is to parse the error string. That’s simply unacceptable, so let’s fix it.

Start with creating a new exception class. Notice that our microservice exception extends RpcException and does not pass a HTTP status code in the constructor. These are the only differences between microservice exceptions and normal Nest.js API exceptions.

export class RpcValidationException extends RpcException {
    constructor(public readonly validationErrors: ValidationError[]) {
        super('Validation failed');
    }
}

We can now change the rpcCreate method to throw this exception when the data is not valid.

@MessagePattern({cmd: 'users.create'})
public async rpcCreate(data: any) {
    if (!data || (data && Object.keys(data).length === 0)) throw new RpcValidationException();

    await this.userService.create(data);
}

Finally, create an exception filter. Microservice exception filters differ from their normal API counterparts by extending RpcExceptionFilter and returning an ErrorObservable. This filter will catch the RpcValidationException we created and throw an object containing a specific error code.

Note the throwError method is from the RxJS version 6 package. If you are still using RxJS version 5, use Observable.throw.

@Catch(RpcValidationException)
export class RpcValidationFilter implements RpcExceptionFilter {
    public catch(exception: RpcValidationException): ErrorObservable {
        return throwError({
            error_code: 'VALIDATION_FAILED',
            error_message: exception.getError(),
            errors: exception.validationErrors
        });
    }
}

All we have left is to act on our new exception when it occurs. Modify the create method to catch any exceptions thrown from the microservice client. In the catch, check if the error_code field has a value of VALIDATION_FAILED. When it does, we can return a 400 HTTP status code back to the user. This will allow the user’s client, the browser, to treat the error differently, possibly showing the user some messaging and allowing them to fix the data entered. This provides a much better user experience compared to throwing all errors back to the client as 500 HTTP status code.

@Post('users')
public async create(@Req() req, @Res() res) {
    this.client.send({cmd: 'users.create'}, body).subscribe({
        next: () => {
            res.status(HttpStatus.CREATED).send();
        },
        error: error => {
            if (error.error_code === 'VALIDATION_FAILED') {
                res.status(HttpStatus.BAD_REQUEST).send(error);
            } else {
                res.status(HttpStatus.INTERNAL_SERVER_ERROR).send(error);
            }
        }
    });
}

Pipes

The most common pipe used with and provided by Nest.js is the ValidationPipe. This pipe, however, cannot be used with microservice handlers because it throws exceptions extending HttpException. All exceptions thrown in a microservice must extend RpcException. To fix this, we can extend the ValidationPipe, catch the HttpException, and throw an RpcException.

@Injectable()
export class RpcValidationPipe extends ValidationPipe implements PipeTransform<any> {
    public async transform(value: any, metadata: ArgumentMetadata) {
        try {
            await super.transform(value, metadata);
        } catch (error) {
            if (error instanceof BadRequestException) {
                throw new RpcValidationException();
            }

            throw error;
        }

        return value;
    }
}

Before we can use the ValidationPipe, we have to create a class that describes the format of the data our microservice method expects.

class CreateUserRequest {
      @IsEmail()
      @IsNotEmpty()
      @IsDefined()
      @IsString()
      public email: string;

      @Length(8)
      @Matches(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)\S+$/)
      @IsDefined()
      @IsString()
      public password: string;

      @IsNotEmpty()
      @IsDefined()
      @IsString()
      public firstName: string;

      @IsNotEmpty()
      @IsDefined()
      @IsString()
      public lastName: string;
}

The new request class uses the class-validator NPM package to validate the object being passed to our microservice method from the Nest.js microservice module. The class contains all the properties with specific decorators to describe what those properties should contain. For example, the email property should be an email address, cannot be empty, must be defined, and must be a string. Now we just need to hook it up to our rpcCreate method.

@MessagePattern({cmd: 'users.create'})
@UsePipes(new RpcValidationPipe())
@UseFilters(new RpcValidationFilter())
public async rpcCreate(data: CreateUserRequest) {
    await this.userService.create(data);
}

Since microservice handlers do not make use of the @Body decorator, we will need to use @UsePipes to make use of our new RpcValidationPipe. This will instruct Nest.js to validation the input data against it’s class type. Just like you would for APIs, use validation classes and the RpcValidationPipe to offload input validation out of your controller or microservice method.

Guards

Guards in microservices serve the same purpose as they do in normal APIs. They determine if a specific microservice handler should handle a request. Up to now, we have used guards to protect API handlers from unauthorized access. We should do the same thing to our microservice handlers. Although in our application, our microservice handler is only called from our already protected API handler, we should never assume that will always be the case.

@Injectable()
export class RpcCheckLoggedInUserGuard implements CanActivate {
    canActivate(context: ExecutionContext): boolean | Promise<boolean> | Observable<boolean> {
        const data = context.switchToRpc().getData();
        return Number(data.userId) === data.user.id;
    }
}

The new guard looks exactly like the API CheckLoggedInUserGuard guard. The difference is in the parameters that are passed to the canActivate method. Since this guard is being executed in the context of a microservice, it will be given a microservice data object instead of the API request object.

We use the new microservice guard the same way we did our API guard. Simply decorate out microservice handler with @UseGuards and our guard will now protect our microservice from misuse. Let’s make a new microservice for retrieving the current user’s information.

@Get('users/:userId')
@UseGuards(CheckLoggedInUserGuard)
public async show(@Param('userId') userId: number, @Req() req, @Res() res) {
    this.client.send({cmd: 'users.show'}, {userId, user: req.user}).subscribe({
        next: user => {
            res.status(HttpStatus.OK).json(user);
        },
        error: error => {
            res.status(HttpStatus.INTERNAL_SERVER_ERROR).send(error);
        }
    });
}

@MessagePattern({cmd: 'users.show'})
@UseGuards(RpcCheckLoggedInUserGuard)
public async rpcShow(data: any) {
    return await this.userService.findById(data.userId);
}

The show API handler now offloads the heavy lifting of accessing the database to the NestMicroservice context. The guard on the microservice handler ensures, if the handler is somehow invoked outside of the show API handler, it will still protect the user data from being exposed to unauthorized requests. But there is still a problem. This example returns the entire user object from the database, including the hashed password. This is a security vulnerability best solved by interceptors.

Interceptors

Microservice interceptors function no differently from normal API interceptors. The only difference is that the interceptor is passed the data object sent to the microservice handler instead of an API request object. This means you can actually write interceptors once and use them in both contexts. Just like API interceptors, microservice interceptors are executed before the microservice handler and must return an Observable. To secure our rpcShow microservice endpoint, we will create a new interceptor that will expect a User database object and remove the password field.

@Injectable()
export class CleanUserInterceptor implements NestInterceptor {
    intercept(context: ExecutionContext, stream$: Observable<any>): Observable<any> {
        return stream$.pipe(
            map(user => JSON.parse(JSON.stringify(user))),
            map(user => {
                return {
                    ...user,
                    password: undefined
                };
            })
        );
    }
}

@MessagePattern({cmd: 'users.show'})
@UseGuards(RpcCheckLoggedInUserGuard)
@UseInterceptors(CleanUserInterceptor)
public async rpcShow(data: any) {
    return await this.userService.findById(data.userId);
}

The response from the rpcShow microservice handler will now have the password field removed. Notice in the interceptor we had to convert the User database object to and from JSON. This may differ depending on the ORM you make use of. With Sequelize, we need to get the raw data from the database response. This is because the response from the ORM is actually a class containing many different ORM methods and properties. By converting it to JSON and back, we can use the spread operator with password: undefined to delete the password field.

Built-in transports

The TCP transport is only one of several transports Nest.js has built-in. Using the TCP transport, we had to bind our NestMicroservice context to an additional port, taking up yet another port on the server, and ensuring our NestMicroservice context was running before starting the NestApplication context. Other built-in transports can overcome these limitations and add additional benefits.

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    app.connectMicroservice({
        transport: Transport.REDIS,
        options: {
            url: process.env.REDIS_URL
        }
    });

    await app.startAllMicroservicesAsync();
    await app.listen(3001);
}

export const microserviceConfig: RedisOptions = {
    transport: Transport.REDIS,
    options: {
        url: process.env.REDIS_URL
    }
};

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    app.connectMicroservice(microserviceConfig);

    await app.startAllMicroservicesAsync();
    await app.listen(3001);
}

@Controller()
export class UserController {
    @Client(microserviceConfig)
    client: ClientProxy
}

export const microserviceConfig: MqttOptions = {
    transport: Transport.MQTT,
    options: {
        url: process.env.MQTT_URL
    }
};

export const microserviceConfig: MqttOptions = {
    transport: Transport.NATS,
    options: {
        url: process.env.NATS_URL
    }
};

syntax = "proto3";

package example.nestBook;

message User {
    string firstName = 1;
    string lastName = 2;
    string email = 3;
}

message ShowUserRequest {
    double userId = 1;
}

message ShowUserResponse {
    User user = 1;
}

service UserService {
    rpc show (ShowUserRequest) returns (ShowUserResponse);
}

export const microserviceConfig: GrpcOptions = {
    transport: Transport.GRPC,
    options: {
        url: '0.0.0.0:5667',
        protoPath: join(__dirname, './nest-book-example.proto'),
        package: 'example.nestBook'
    }
};

@Controller()
export class UserController implements OnModuleInit {
    @Client(microserviceConfig)
    private client: ClientGrpc;
    private protoUserService: IProtoUserService;

    constructor(
        private readonly userService: UserService
    ) {
    }

    public onModuleInit() {
        this.protoUserService = this.client.getService<IProtoUserService>('UserService');
    }
}

import { Observable } from 'rxjs';

export interface IProtoUserService {
    show(data: any): Observable<any>;
}

@Get('users/:userId')
@UseGuards(CheckLoggedInUserGuard)
public async show(@Param('userId') userId: number, @Req() req, @Res() res) {
    this.protoUserService.show({ userId: parseInt(userId.toString(), 10) }).subscribe({
        next: user => {
            res.status(HttpStatus.OK).json(user);
        },
        error: error => {
            res.status(HttpStatus.INTERNAL_SERVER_ERROR).json(error);
        }
    });
}

@GrpcMethod('UserService', 'show')
public async rpcShow(data: any) {
    const user =  await this.userService.findById(data.userId);
    return {
        user: {
            firstName: user.firstName,
            lastName: user.lastName,
            email: user.email
        }
    };
}

export class UserController implements OnModuleInit {
    @GrpcMethod()
    public async rpcShow(data: any) {
    }
}

Custom transport

A custom transport allows you to define a new microservice client and server for communicating between the NestApplication and NestMicroservice contexts. You may want to create a custom transport strategy for a number of reasons: you or your company already have a message broker service that is does not have a built-in Nest.js transport, or you need to customize how one of the built-in transports works. For the purpose of our example, we will work through implementing a new RabbitMQ transport.

export class RabbitMQTransportServer extends Server implements CustomTransportStrategy {
    private server: amqp.Connection = null;
    private channel: amqp.Channel = null;

    constructor(
        private readonly url: string,
        private readonly queue: string
    ) {
        super();
    }
}

Nest.js requires all custom transports to implement the CustomTransportStrategy interface. This forces us to define our own listen and close methods. In our example, we connect to the RabbitMQ server and listen on a specific channel. Closing the server is as simple as disconnecting from the RabbitMQ server.

public async listen(callback: () => void) {
    await this.init();
    callback();
}

public close() {
    this.channel && this.channel.close();
    this.server && this.server.close();
}

private async init() {
    this.server = await amqp.connect(this.url);
    this.channel = await this.server.createChannel();
    this.channel.assertQueue(`${this.queue}_sub`, { durable: false });
    this.channel.assertQueue(`${this.queue}_pub`, { durable: false });
}

By extending the Nest.js Server class, our custom transport comes pre-equipped with the RxJS handling of messages that makes Nest.js so great. However, our custom transport isn’t really handling messages at this point. We need to add the logic for how messages will be sent and received through RabbitMQ to our custom transport.

public async listen(callback: () => void) {
    await this.init();
    this.channel.consume(`${this.queue}_sub`, this.handleMessage.bind(this), {
        noAck: true,
    });
    callback();
}

private async handleMessage(message: amqp.Message) {
    const { content } = message;
    const packet = JSON.parse(content.toString()) as ReadPacket & PacketId;
    const handler = this.messageHandlers[JSON.stringify(packet.pattern)];

    if (!handler) {
        return this.sendMessage({
            id: packet.id,
            err: NO_PATTERN_MESSAGE
        });
    }

    const response$ = this.transformToObservable(await handler(packet.data)) as Observable<any>;
    response$ && this.send(response$, data => this.sendMessage({
        id: packet.id,
        ...data
    }));
}

private sendMessage(packet: WritePacket & PacketId) {
    const buffer = Buffer.from(JSON.stringify(packet));
    this.channel.sendToQueue(`${this.queue}_pub`, buffer);
}

The custom transport will now listen for incoming messages on the sub channel and send responses on the pub channel. The handleMessage method decodes the message’s content byte array and uses the embedded pattern object to find the correct microservice handler to service the message. For example, the {cmd: 'users.create'} will be handled by the rpcCreate handler. Finally, we call the handler, transform the response into an Observable, and pass that back into the Nest.js Server class. Once a response is provided, it will be passed on to our sendMessage method and out through the pub channel.

Since a server is useless without a client, we will need to create one of those too. The RabbitMQ client must extend the Nest.js ClientProxy class and provide an override for the close, connect, and publish methods.

export class RabbitMQTransportClient extends ClientProxy {
    private server: amqp.Connection;
    private channel: amqp.Channel;
    private responsesSubject: Subject<amqp.Message>;

    constructor(
        private readonly url: string,
        private readonly queue: string) {
        super();
    }

    public async close() {
        this.channel && await this.channel.close();
        this.server && await this.server.close();
    }

    public connect(): Promise<void> {
        return new Promise(async (resolve, reject) => {
            try {
                this.server = await amqp.connect(this.url);
                this.channel = await this.server.createChannel();

                const { sub, pub } = this.getQueues();
                await this.channel.assertQueue(sub, { durable: false });
                await this.channel.assertQueue(pub, { durable: false });

                this.responsesSubject = new Subject();
                this.channel.consume(pub, (message) => { this.responsesSubject.next(message); }, { noAck: true });
                resolve();
            } catch (error) {
                reject(error);
            }
        });
    }

    protected async publish(partialPacket: ReadPacket, callback: (packet: WritePacket) => void) {
    }

    private getQueues() {
        return { pub: `${this.queue}_pub`, sub: `${this.queue}_sub` };
    }
}

In our example, we created a new connection to the RabbitMQ server and the specified pub and sub channels. The client uses the channels in an opposite configuration compared to the server. The client sends messages through the sub channel and listens for responses on the pub channel. We also make use of the power of RxJS by piping all responses into a Subject to make processing simpler in the publish method. Let’s implement the publish method.

protected async publish(partialPacket: ReadPacket, callback: (packet: WritePacket) => void) {
    if (!this.server || !this.channel) {
        await this.connect();
    }

    const packet = this.assignPacketId(partialPacket);
    const { sub } = this.getQueues();

    this.responsesSubject.asObservable().pipe(
        pluck('content'),
        map(content => JSON.parse(content.toString()) as WritePacket & PacketId),
        filter(message => message.id === packet.id),
        take(1)
    ).subscribe(({err, response, isDisposed}) => {
        if (isDisposed || err) {
            callback({
                err,
                response: null,
                isDisposed: true
            });
        }

        callback({err, response});
    });

    this.channel.sendToQueue(sub, Buffer.from(JSON.stringify(packet)));
}

The publish method starts off with assigning a unique ID to the message and subscribes to the response subject for sending the response back to the microservice caller. Finally, sendToQueue is called to send the message as a byte array to the sub channel. Once a response is received, the subscription to the response subject is fired. The first thing the subscription stream does is extract the content of the response and verify that the message ID matches the one that was assigned when publish was initially called. This keeps the client from processing a message response that does not belong to the specific publish execution context. Put simply, the client will receive every microservice response, even those that might be for a different microservice or a different execution of the same microservice. If the IDs match, the client checks fir errors and uses the callback to send the response back to the microservice caller.

Before we can use our new transport, we will need to update the microservice configuration object we created earlier.

export const microserviceConfig = {
    url: process.env.AMQP_URL
};

export const microserviceServerConfig: (channel: string) => CustomStrategy = channel => {
    return {
        strategy: new RabbitMQTransportServer(microserviceConfig.url, channel)
    }
};

We now have a method that will instantiate our custom transport server. This is used in the bootstrap of our application to connect our NestMicroservice context to the RabbitMQ server.

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    app.connectMicroservice(microserviceServerConfig('nestjs_book'));

    await app.startAllMicroservicesAsync();
    await app.listen(3001);
}

The last piece of our custom transport is in our controller. Since we are using a custom transport, we can no longer use the @ClientProxy decorator. Instead, we have to instantiate our custom transport our selves. You could do this in the constructor as so:

@Controller()
export class UserController {
    client: ClientProxy;

    constructor(private readonly userService: UserService) {
        this.client = new RabbitMQTransportClient(microserviceConfig.url, 'nestjs_book');
    }
}

Wait! You have now created a hard binding between the controller and the custom transport client. This makes it more difficult to migrate to a different strategy in the future and very difficult to test. Instead, let’s make use of Nest.js’s fabulous Dependency Injection to create our client. Start off with creating a new module to house and expose our custom transport client.

const ClientProxy = {
  provide: 'ClientProxy',
  useFactory: () => new RabbitMQTransportClient(microserviceConfig.url, 'nestjs_book')
};

@Module({
    imports: [],
    controllers: [],
    components: [ClientProxy],
    exports: [ClientProxy]
})
export class RabbitMQTransportModule {}

In our example, we gave our component the injection token 'ClientProxy'. This was just to keep things simple, and you can call it whatever you like. The import part is to make sure the injection token used to register the component is also the one used in the @Inject decorator we place in our controller’s constructor.

@Controller()
export class UserController {

    constructor(
        private readonly userService: UserService,
        @Inject('ClientProxy')
        private readonly client: ClientProxy
    ) {
    }

Our controller will now have a microservice client injected in at run time allowing the API handlers to communicate with the microservice handlers. Even better, the client can now be overridden in tests with a mock. Startup a RabbitMQ server, such as the rabbitmq docker image , and setup the AMQP_URL environment variable, ie amqp://guest:guest@localhost:5672, and all microservice requests will be processed through the RabbitMQ server.

The data flow and how the microservice client and server operate in our RabbitMQ example are almost identical to the NATS transport. Just like with NATS, RabbitMQ provides the ability to have multiple NestMicroservice contexts consuming messages. RabbitMQ will work to load balance between all the consumers.

Hybrid application

When we first started our microservice implementation in this chapter, we modified the bootstrap method to call connectMicroservice. This is a special method that converts our Nest.js application into a hybrid application. This simply means our application now contains multiple context types. Simple enough but this has some implications that you should be aware of. Specifically, using the hybrid application approach, you will no longer be able to attach global filters, pipes, guards, and interceptors for the NestMicroservice context. This is because the NestMicroservice context is immediately bootstrapped, but not connected, in a hybrid application. To get around this limitation, we can create our two contexts independently.

async function bootstrap() {
    const app = await NestFactory.create(AppModule);
    const rpcApp = await NestFactory.createMicroservice(AppModule, microserviceServerConfig('nestjs_book'));
    rpcApp.useGlobalFilters(new RpcValidationFilter());

    await rpcApp.listenAsync();
    await app.listen(process.env.PORT || 3000);
}

Now that we are creating the two application contexts independently, we can make use of globals for the NestMicroservice context. To test this, we can update the rpcCreate handler to remove the RpcValidationFilter. Executing the application at this point should still result in validation errors being returned when the request to the create API does not contain required fields.

@MessagePattern({cmd: 'users.create'})
public async rpcCreate(data: CreateUserRequest) {
    if (!data || (data && Object.keys(data).length === 0)) throw new RpcValidationException();
    await this.userService.create(data);
}

We can extend this approach of bootstrapping our application to split even more of our application into separate contexts. This still does not make use of multiple processes or threads, but employing some more advanced architecture design, we can gain those benefits.

Advanced architecture design

So far we have covered everything needed to setup and start writing and using microservices in Nest.js. Along the way we describe some of the drawbacks Nest.js’ implementation of microservices has. Most notably, since the microservices does not run in a separate thread or process, you may not be gaining much in the way of performance when using Nest.js microservices.

However, that is not to say you can’t get these benefits. Nest.js just doesn’t provide the tools out of the box. In most material found on the subject of running a NodeJS application in production, the one thing that is typically always covered and recommended is the use of the NodeJS cluster module. We can do the same thing with our Nest.js application.

async function bootstrapApp() {
    const app = await NestFactory.create(AppModule);

    await app.listen(process.env.PORT || 3000);
}

async function bootstrapRpc() {
    const rpcApp = await NestFactory.createMicroservice(AppModule, microserviceServerConfig('nestjs_book'));
    rpcApp.useGlobalFilters(new RpcValidationFilter());

    await rpcApp.listenAsync();
}

if (cluster.isMaster) {
    const appWorkers = [];
    const rpcWorkers = [];

    for (let i = 0; i < os.cpus().length; i++) {
        const app = cluster.fork({
            APP_TYPE: 'NestApplication'
        });
        const rpc = cluster.fork({
            APP_TYPE: 'NestMicroservice'
        });

        appWorkers.push(app);
        rpcWorkers.push(rpc);
    }

    cluster.on('exit', function(worker, code, signal) {
        if (appWorkers.indexOf(worker) > -1) {
            const index = appWorkers.indexOf(worker);
            const app = cluster.fork({
                APP_TYPE: 'NestApplication'
            });
            appWorkers.splice(index, 1, app);
        } else if (rpcWorkers.indexOf(worker) > -1) {
            const index = rpcWorkers.indexOf(worker);
            const rpc = cluster.fork({
                APP_TYPE: 'NestMicroservice'
            });
            rpcWorkers.splice(index, 1, rpc);
        }
    });
} else {
    if (process.env.APP_TYPE === 'NestApplication') {
        bootstrapApp();
    } else if (process.env.APP_TYPE === 'NestMicroservice') {
        bootstrapRpc();
    }
}

Now, not only does our NestApplication and NestMicroservice contexts run on their own threads, they are also clustered according to the number of CPUs available on the server. For each CPU, a separate NestApplication and NestMicroservice context will be created. The NestApplication context threads will share the main application port. Finally, since we are using RabbitMQ, having multiple NestMicroservice contexts running, we have multiple subscribers waiting for microservice messages. RabbitMQ will take care of load balancing message distribution between all of our NestMicroservice instances. We have made our application more resilient and better equipped to handle a heavier load of users than what it was at the beginning of this chapter.

Summary

At the beginning of this chapter, we stated “microservice” was a misleading name for this part of Nest.js. In fact, that could still be the case, but it really depends on a number of factors. Our initial example using the TCP transport could hardly qualify as a microservice by all conventional definitions. Both the NestApplication and NestMicroservice context were executing from the same process, meaning a catastrophic failure in one could bring both down.

After highlighting all the transports, Nest.js comes with out-of-the-box, and we re-implemented our microservices in the example blog application using a custom RabbitMQ transport. We even went as far as running the NestApplication and NestMicroservice contexts in their own thread. This was a major step in the right direction for fulfilling the “microservice” name.

Although we didn’t cover specifics in this book, it should now be apparent that you’re not limited to using microservices defined in the same Nest.js project or repository. Using transports like Redis and RabbitMQ, we could create and use multiple Nest.js projects for the sole purpose of executing a NestMicroservice context. All of these projects can be running independently inside a Kubernetes cluster and accessed by passing messages via Redis or RabbitMQ. Even better, we can use the built-in gRPC transport to communicate with microservices wrote in other languages and deployed to other platforms.

In the next chapter we will learn about routing and request handling in Nest.js.