Microservice transports in NestJS - Mini Project: Build & Apply

Microservice transports

📖 Scenario: You are building a simple microservice system with NestJS. An API gateway receives HTTP requests and forwards them to a user microservice via TCP transport. The user microservice handles the business logic and returns results.

🎯 Goal: Set up a NestJS microservice with TCP transport, create message handlers, and connect a client from the API gateway to communicate with the microservice.

📋 What You'll Learn

Create a TCP microservice that listens on port 3001

Define a message handler using @MessagePattern

Register a ClientProxy in the API gateway module

Send messages from the gateway controller to the microservice

💡 Why This Matters

🌍 Real World

Microservice transports are the backbone of distributed NestJS applications, enabling services to communicate reliably across different deployment environments.

💼 Career

Understanding transport layers is essential for backend developers building scalable microservice architectures with NestJS.

1

Create the TCP microservice

In the user microservice's main.ts, create a NestJS microservice using Transport.TCP listening on host 0.0.0.0 and port 3001.

NestJS

import { NestFactory } from '@nestjs/core';
import { Transport } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  // Use createMicroservice with TCP transport on port 3001
  // Your code here
}
bootstrap();

Hint

Use NestFactory.createMicroservice(AppModule, { transport: Transport.TCP, options: { host: '0.0.0.0', port: 3001 } }).

2

Create a message handler

In the user microservice controller, create a method getUser decorated with @MessagePattern({ cmd: 'get_user' }) that receives a data object with an id property and returns a user object with id and name.

NestJS

import { Controller } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

@Controller()
export class UsersController {
  // Add @MessagePattern with cmd 'get_user'
  // Return user object with id and name
  // Your code here
}

Hint

Use @MessagePattern({ cmd: 'get_user' }) above your handler method.

3

Register ClientProxy in gateway module

In the API gateway's module, register a ClientsModule with a TCP client named USER_SERVICE that connects to the user microservice on localhost:3001.

NestJS

import { Module } from '@nestjs/common';
import { ClientsModule, Transport } from '@nestjs/microservices';
import { GatewayController } from './gateway.controller';

@Module({
  imports: [
    // Use ClientsModule.register with TCP transport
    // Name it 'USER_SERVICE' connecting to port 3001
    // Your code here
  ],
  controllers: [GatewayController],
})
export class GatewayModule {}

Hint

Use ClientsModule.register([{ name: 'USER_SERVICE', transport: Transport.TCP, options: { host: 'localhost', port: 3001 } }]).

4

Send messages from gateway controller

In the gateway controller, inject the USER_SERVICE client using @Inject('USER_SERVICE') and create a GET endpoint /users/:id that sends a get_user message to the microservice with the user ID.

NestJS

import { Controller, Get, Param, Inject } from '@nestjs/common';
import { ClientProxy } from '@nestjs/microservices';

@Controller('users')
export class GatewayController {
  // Inject USER_SERVICE client
  // Create GET endpoint that sends get_user message
  // Your code here
}

Hint

Inject with @Inject('USER_SERVICE') private client: ClientProxy and send with this.client.send({ cmd: 'get_user' }, { id }).

Practice

1. Which transport method in NestJS microservices is best suited for simple, direct communication between services on the same network without message brokering?

easy

A. TCP transport

B. Redis transport

C. RabbitMQ transport

D. Kafka transport

Solution

1. Step 1: Understand transport types in NestJS

   TCP transport is a simple protocol for direct communication between services on the same network without needing a message broker.

2. Step 2: Compare with other transports

   Redis, RabbitMQ, and Kafka are message brokers used for more complex messaging patterns and scalability.

3. Final Answer:

   TCP transport -> Option A

4. Quick Check:

   Direct network communication = TCP transport [OK]

Hint: Direct service communication without brokers uses TCP transport [OK]

Common Mistakes:

• Confusing Redis or RabbitMQ as direct transports
• Thinking Kafka is a simple direct transport
• Assuming TCP requires a message broker

2. Which of the following is the correct way to set up a RabbitMQ transport in a NestJS microservice?

easy

A. Transport.KAFKA with topic and brokers

B. Transport.TCP with host and port only

C. Transport.REDIS with channel and password

D. Transport.RMQ with options including urls and queue

Solution

1. Step 1: Identify RabbitMQ transport setup

   RabbitMQ transport in NestJS uses Transport.RMQ and requires options like urls (connection strings) and queue name.

2. Step 2: Differentiate from other transports

   TCP uses host and port, Redis uses channel and password, Kafka uses topic and brokers, so these are incorrect for RabbitMQ.

3. Final Answer:

   Transport.RMQ with options including urls and queue -> Option D

4. Quick Check:

   RabbitMQ setup = Transport.RMQ + urls + queue [OK]

Hint: RabbitMQ transport always uses Transport.RMQ with urls and queue [OK]

Common Mistakes:

• Using TCP options for RabbitMQ
• Confusing Redis channel with RabbitMQ queue
• Omitting urls in RabbitMQ config

3. Given the following NestJS microservice code snippet, what will be the output when a message is sent to the Redis transport?

const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.REDIS,
  options: { url: 'redis://localhost:6379' }
});

app.listen(() => console.log('Microservice is listening'));

medium

A. Microservice failed to start due to invalid transport

B. Error: Missing queue or channel option

C. Microservice is listening

D. Microservice connected to RabbitMQ

Solution

1. Step 1: Analyze the transport configuration

   The code uses Transport.REDIS with a valid Redis URL, which is sufficient for Redis transport in NestJS.

2. Step 2: Understand the listen callback

   The listen method's callback logs 'Microservice is listening' when the microservice starts successfully.

3. Final Answer:

   Microservice is listening -> Option C

4. Quick Check:

   Valid Redis config logs listening message [OK]

Hint: Valid Redis transport logs 'Microservice is listening' on start [OK]

Common Mistakes:

• Expecting queue option for Redis transport
• Confusing Redis with RabbitMQ setup
• Assuming error without testing listen callback

4. Identify the error in this NestJS microservice transport configuration:

const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.RMQ,
  options: {
    urls: ['amqp://localhost:5672'],
    queue: ''
  }
});

medium

A. The urls array should be a string, not an array

B. The queue name is empty, which is invalid

C. Transport should be TCP, not RMQ

D. Missing Redis password in options

Solution

1. Step 1: Check RMQ options correctness

   RabbitMQ transport requires a non-empty queue name to route messages properly.

2. Step 2: Validate other options

   The urls option is correctly an array of connection strings; transport RMQ is correct; Redis password is irrelevant here.

3. Final Answer:

   The queue name is empty, which is invalid -> Option B

4. Quick Check:

   Empty queue name causes config error [OK]

Hint: RabbitMQ queue name must not be empty [OK]

Common Mistakes:

• Thinking urls must be a string
• Confusing transport type with Redis
• Ignoring empty queue name error

5. You need to design a NestJS microservice system that can handle high message throughput with guaranteed message delivery and supports multiple consumers. Which transport should you choose and why?

hard

A. RabbitMQ transport, because it supports message queues with acknowledgments and multiple consumers

B. Redis transport, because it supports pub/sub and persistence

C. TCP transport, because it is simple and fast for high throughput

D. In-memory transport, because it is the fastest for local communication

Solution

1. Step 1: Identify requirements for high throughput and guaranteed delivery

   Guaranteed delivery and multiple consumers require a message broker with queueing and acknowledgment features.

2. Step 2: Evaluate transport options

   TCP is simple but lacks message queueing; Redis supports pub/sub but has limited message durability; RabbitMQ supports queues, acknowledgments, and multiple consumers; in-memory is local only and not scalable.

3. Final Answer:

   RabbitMQ transport, because it supports message queues with acknowledgments and multiple consumers -> Option A

4. Quick Check:

   Guaranteed delivery + multiple consumers = RabbitMQ [OK]

Hint: Use RabbitMQ for guaranteed delivery and multiple consumers [OK]

Common Mistakes:

• Choosing TCP for guaranteed delivery
• Assuming Redis persistence equals RabbitMQ reliability
• Using in-memory transport for distributed systems