Microservice transports in NestJS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set the transport type for a microservice in NestJS.

NestJS

const microservice = app.connectMicroservice({ transport: Transport.[1] });

Drag options to blanks, or click blank then click option'

ATCP

BGRPC

CHTTP

DWEBSOCKET

Attempts:

3 left

💡 Hint

Common Mistakes

Using HTTP as a transport in microservice setup instead of TCP.

Confusing GRPC with TCP transport.

The Transport.TCP option sets the microservice to use TCP transport, which is common for NestJS microservices.

2fill in blank

medium

Complete the code to create a microservice client using Redis transport in NestJS.

NestJS

const client = ClientProxyFactory.create({ transport: Transport.[1], options: { url: 'redis://localhost:6379' } });

Drag options to blanks, or click blank then click option'

AREDIS

BTCP

CMQTT

DNATS

Attempts:

3 left

💡 Hint

Common Mistakes

Using TCP transport with Redis URL.

Confusing MQTT or NATS with Redis transport.

The Transport.REDIS option configures the client to use Redis as the transport layer for messaging.

3fill in blank

hard

Fix the error in the microservice setup by selecting the correct transport option.

NestJS

app.connectMicroservice({ transport: Transport.[1] });

Drag options to blanks, or click blank then click option'

AHTTP

BTCP

CGRPC

DREDIS

Attempts:

3 left

💡 Hint

Common Mistakes

Using TCP or HTTP transport for gRPC microservices.

Misspelling the transport option.

For gRPC transport, use Transport.GRPC to properly configure the microservice.

4fill in blank

hard

Fill both blanks to configure a microservice with MQTT transport and specify the broker URL.

NestJS

app.connectMicroservice({ transport: Transport.[1], options: { url: '[2]' } });

Drag options to blanks, or click blank then click option'

AMQTT

Bredis://localhost:6379

Cmqtt://broker.hivemq.com

DTCP

Attempts:

3 left

💡 Hint

Common Mistakes

Using Redis URL with MQTT transport.

Using TCP transport with MQTT broker URL.

Use Transport.MQTT for MQTT transport and specify the broker URL like mqtt://broker.hivemq.com.

5fill in blank

hard

Fill all three blanks to create a client proxy with NATS transport, specify the URL, and set the queue name.

NestJS

const client = ClientProxyFactory.create({ transport: Transport.[1], options: { url: '[2]', queue: '[3]' } });

Drag options to blanks, or click blank then click option'

ANATS

Bnats://localhost:4222

Cmy_queue

Dmqtt://broker.hivemq.com

Attempts:

3 left

💡 Hint

Common Mistakes

Using MQTT URL with NATS transport.

Omitting the queue name in options.

Use Transport.NATS for NATS transport, specify the NATS server URL, and set the queue name as needed.

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