Why Message patterns (request-response) in NestJS? - Purpose & Use Cases

The Big Idea

Discover how NestJS message patterns turn complex message handling into simple, clean code!

The Scenario

Imagine building a server where every time a client sends a request, you manually listen for messages, parse them, and send back responses using low-level code.

You have to write code to handle each message type, check for errors, and manage responses yourself.

The Problem

This manual approach is slow and error-prone because you must write repetitive code for each message type.

It's easy to forget to send a response or handle errors properly, leading to bugs and confusing behavior.

The Solution

Message patterns in NestJS let you define clear request-response handlers using decorators.

The framework automatically routes messages to the right handler and manages responses, so you focus on your business logic.

Before vs After

✗ Before

listenToMessage('getUser', (data) => { /* parse data */ /* fetch user */ /* send response */ })

✓ After

@MessagePattern('getUser')
handleGetUser(data) {
  return this.userService.findUser(data.id);
}

What It Enables

This makes building scalable, maintainable microservices easy by cleanly separating message handling and response logic.

Real Life Example

In a chat app, when a client requests user info, the server automatically routes the request to the right handler and sends back the user data without extra plumbing code.

Key Takeaways

Manual message handling is repetitive and error-prone.

Message patterns in NestJS simplify request-response communication.

They improve code clarity and reduce bugs in microservices.

Practice

1. What is the main purpose of the @MessagePattern decorator in NestJS?

easy

A. To define HTTP routes in a controller

B. To listen for specific message types and handle incoming messages

C. To send messages to other microservices

D. To configure database connections

Solution

1. Step 1: Understand the role of @MessagePattern

   This decorator is used to mark a method that listens for messages matching a specific pattern.

2. Step 2: Differentiate from other decorators

   Unlike HTTP route decorators, @MessagePattern is for message-based communication, not HTTP or database setup.

3. Final Answer:

   To listen for specific message types and handle incoming messages -> Option B

4. Quick Check:

   @MessagePattern listens for messages [OK]

Hint: Remember: @MessagePattern listens, not sends [OK]

Common Mistakes:

• Confusing @MessagePattern with HTTP route decorators
• Thinking it sends messages instead of listening
• Assuming it configures databases

2. Which of the following is the correct way to define a message handler for the pattern 'sum_numbers' in NestJS?

easy

A. @Subscribe('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

B. @Get('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

C. @Post('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

D. @MessagePattern('sum_numbers')
handleSum(data: number[]) { return data.reduce((a, b) => a + b); }

Solution

1. Step 1: Identify the correct decorator for message patterns

   @MessagePattern is the correct decorator to listen for messages, not @Get, @Post, or @Subscribe.

2. Step 2: Confirm the syntax

   The pattern string 'sum_numbers' is correctly passed as an argument to @MessagePattern, and the handler method processes the data.

3. Final Answer:

   @MessagePattern('sum_numbers') handleSum(data: number[]) { return data.reduce((a, b) => a + b); } -> Option D

4. Quick Check:

   Use @MessagePattern('pattern') for message handlers [OK]

Hint: Use @MessagePattern for message handlers, not HTTP decorators [OK]

Common Mistakes:

• Using HTTP decorators like @Get or @Post for message patterns
• Using non-existent decorators like @Subscribe
• Forgetting to pass the pattern string to @MessagePattern

3. Given the following NestJS message handler, what will be the response when the message pattern 'multiply' is sent with data [2, 3]?

@MessagePattern('multiply')
handleMultiply(data: number[]) {
  return data[0] * data[1];
}

medium

A. 6

B. undefined

C. [2, 3]

D. 5

Solution

1. Step 1: Understand the handler logic

   The handler receives an array of numbers and returns the product of the first two elements: data[0] * data[1].

2. Step 2: Calculate the product for input [2, 3]

   2 * 3 equals 6, so the response will be 6.

3. Final Answer:

   6 -> Option A

4. Quick Check:

   2 multiplied by 3 equals 6 [OK]

Hint: Multiply first two array elements for 'multiply' pattern [OK]

Common Mistakes:

• Adding instead of multiplying the numbers
• Returning the input array instead of the product
• Assuming undefined because of missing return

4. Identify the error in the following NestJS message handler code:

@MessagePattern('greet')
async handleGreet(name: string) {
  console.log('Greeting:', name);
}

medium

A. The @MessagePattern decorator is missing the pattern string

B. The method should not be async

C. The handler does not return a response to the sender

D. The parameter type should be an object, not a string

Solution

1. Step 1: Check the handler's return behavior

   The handler logs the name but does not return any value, so the sender gets no response.

2. Step 2: Verify decorator and parameter correctness

   The decorator has the pattern string 'greet', and the parameter type string is acceptable for simple messages.

3. Final Answer:

   The handler does not return a response to the sender -> Option C

4. Quick Check:

   Handlers must return a response [OK]

Hint: Always return a value in message handlers [OK]

Common Mistakes:

• Not returning a response causes sender to wait indefinitely
• Confusing async usage with missing return
• Assuming parameter type must be object always

5. You want to create a NestJS microservice that listens for a message pattern 'calculate' and returns the sum of two numbers sent in an object like { a: 5, b: 7 }. Which of the following handler implementations correctly achieves this?

hard

A. @MessagePattern('calculate')
handleCalculate(data: { a: number; b: number }) {
return data.a + data.b;
}

B. @MessagePattern('calculate')
handleCalculate(a: number, b: number) {
return a + b;
}

C. @MessagePattern('calculate')
handleCalculate(data: number[]) {
return data[0] + data[1];
}

D. @MessagePattern('calculate')
handleCalculate(data: string) {
return parseInt(data);
}

Solution

1. Step 1: Match the expected input structure

   The message sends an object with properties a and b, so the handler must accept an object with those properties.

2. Step 2: Verify the handler logic

   The handler correctly accesses data.a and data.b and returns their sum.

3. Step 3: Check other options for correctness

   @MessagePattern('calculate') handleCalculate(a: number, b: number) { return a + b; } expects two separate parameters, which does not match the single object sent. @MessagePattern('calculate') handleCalculate(data: number[]) { return data[0] + data[1]; } expects an array, and @MessagePattern('calculate') handleCalculate(data: string) { return parseInt(data); } expects a string, both incorrect.

4. Final Answer:

   @MessagePattern('calculate') handleCalculate(data: { a: number; b: number }) { return data.a + data.b; } -> Option A

5. Quick Check:

   Match input shape and sum properties [OK]

Hint: Match handler parameter to message data shape exactly [OK]

Common Mistakes:

• Using multiple parameters instead of one object
• Expecting array when object is sent
• Parsing string instead of object