Microservice transports in NestJS

Introduction

Microservice transports help different small services talk to each other easily and reliably.

When you want to split a big app into smaller parts that work independently.

When services need to send messages or data to each other quickly.

When you want to choose the best way for services to communicate, like using HTTP or messaging queues.

When you want to make your app easier to grow and fix without stopping everything.

When you want to handle many users or requests without slowing down.

Syntax

NestJS

import { Transport } from '@nestjs/microservices';

const microserviceOptions = {
  transport: Transport.TCP, // e.g. Transport.REDIS, Transport.NATS, Transport.RMQ, Transport.GRPC
  options: {
    // transport-specific options like host, port, queue name
  },
};

Choose the transport type based on your communication needs.

Each transport has its own options to configure connection details.

Examples

Use TCP transport for simple direct communication between services.

NestJS

const tcpMicroservice = {
  transport: Transport.TCP,
  options: { host: '127.0.0.1', port: 3001 },
};

Use Redis transport for pub/sub messaging with Redis server.

NestJS

const redisMicroservice = {
  transport: Transport.REDIS,
  options: { url: 'redis://localhost:6379' },
};

Use RabbitMQ transport for reliable message queues.

NestJS

const rmqMicroservice = {
  transport: Transport.RMQ,
  options: { urls: ['amqp://localhost:5672'], queue: 'main_queue' },
};

Sample Program

This example shows how to create a simple NestJS microservice using TCP transport. The service listens on port 4000 for incoming messages from other services.

NestJS

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

async function bootstrap() {
  // Create a microservice using TCP transport
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.TCP,
    options: { host: '127.0.0.1', port: 4000 },
  });

  await app.listen();
  console.log('Microservice is listening on TCP port 4000');
}

bootstrap();

Important Notes

Pick the transport that fits your app's needs for speed, reliability, and complexity.

TCP is simple but less flexible; message brokers like RabbitMQ add reliability and features.

Always configure transports with correct host, port, and credentials to avoid connection issues.

Summary

Microservice transports let small services communicate in different ways.

Choose transports like TCP, Redis, or RabbitMQ based on your app's needs.

Proper setup helps your app grow and handle many users smoothly.

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