Gateway decorator in NestJS - Performance & Optimization

Performance: Gateway decorator

MEDIUM IMPACT

This affects the initialization and event handling speed of WebSocket gateways in a NestJS application, impacting interaction responsiveness.

Defining a WebSocket gateway to handle real-time events

NestJS

import { WebSocketGateway, SubscribeMessage } from '@nestjs/websockets';

@WebSocketGateway()
export class ChatGateway {
  @SubscribeMessage('message')
  async handleMessage(client: any, payload: any) {
    // offload heavy work asynchronously
    await new Promise(resolve => setTimeout(resolve, 0));
    return { event: 'message', data: payload };
  }
}

Offloading heavy work asynchronously prevents blocking the event loop, improving responsiveness.

📈 Performance GainNon-blocking event handler improves INP by reducing input delay to near instant.

Defining a WebSocket gateway to handle real-time events

NestJS

import { WebSocketGateway, SubscribeMessage } from '@nestjs/websockets';

@WebSocketGateway()
export class ChatGateway {
  @SubscribeMessage('message')
  handleMessage(client: any, payload: any) {
    // heavy synchronous processing
    for(let i = 0; i < 1000000000; i++) {}
    return { event: 'message', data: payload };
  }
}

Heavy synchronous processing inside event handlers blocks the event loop, delaying response and reducing interaction speed.

📉 Performance CostBlocks event loop causing high INP, delays user interaction response by hundreds of milliseconds.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Heavy synchronous event handler	N/A	N/A	N/A	[X] Bad
Asynchronous lightweight event handler	N/A	N/A	N/A	[OK] Good

Rendering Pipeline

The Gateway decorator sets up WebSocket event listeners during server initialization. When events occur, handlers run in the Node.js event loop affecting responsiveness.

→Event Listener Setup

→Event Loop Processing

→Response Dispatch

⚠️ BottleneckEvent Loop Processing when handlers perform heavy synchronous work

Core Web Vital Affected

INP

This affects the initialization and event handling speed of WebSocket gateways in a NestJS application, impacting interaction responsiveness.

Optimization Tips

1Keep Gateway event handlers lightweight and asynchronous to avoid blocking the event loop.

2Specify namespaces in the Gateway decorator to scope event handling and reduce unnecessary load.

3Avoid heavy synchronous processing inside WebSocket event handlers to maintain fast interaction responsiveness.

Performance Quiz - 3 Questions

What is the main performance risk of heavy synchronous code inside a Gateway event handler?

A It causes layout shifts on the page.

B It increases CSS paint time.

C It blocks the event loop, causing slow response to user interactions.

D It increases bundle size significantly.

DevTools: Performance

How to check: Record a session while interacting with the WebSocket features; look for long tasks blocking the main thread.

What to look for: Long tasks or event loop blocking delays indicate poor Gateway handler performance.

Practice

1.

What is the main purpose of the @WebSocketGateway() decorator in NestJS?

easy

A. To turn a class into a WebSocket gateway for real-time communication

B. To create a REST API controller

C. To define a database entity

D. To handle HTTP middleware

Solution

1. Step 1: Understand the role of @WebSocketGateway()

   This decorator marks a class as a WebSocket gateway, enabling real-time communication between server and clients.

2. Step 2: Compare with other options

   Options B, C, and D relate to REST controllers, database entities, and middleware, which are unrelated to WebSocket gateways.

3. Final Answer:

   To turn a class into a WebSocket gateway for real-time communication -> Option A

4. Quick Check:

   @WebSocketGateway() creates WebSocket gateways [OK]

Hint: Remember: Gateway decorator = real-time WebSocket server [OK]

Common Mistakes:

• Confusing WebSocketGateway with REST controllers
• Thinking it creates database entities
• Assuming it handles HTTP middleware

2.

Which of the following is the correct syntax to create a WebSocket gateway with a custom namespace /chat?

?

easy

A. @WebSocketGateway(namespace: '/chat')
export class ChatGateway {}

B. @WebSocketGateway('/chat')
export class ChatGateway {}

C. @WebSocketGateway({ namespace: '/chat' })
export class ChatGateway {}

D. @WebSocketGateway({ path: '/chat' })
export class ChatGateway {}

Solution

1. Step 1: Recall the correct options object syntax

   The @WebSocketGateway() decorator accepts an options object where namespace is a valid key to set the namespace.

2. Step 2: Evaluate each option

   @WebSocketGateway({ namespace: '/chat' }) export class ChatGateway {} correctly uses { namespace: '/chat' }. @WebSocketGateway('/chat') export class ChatGateway {} incorrectly passes a string directly. @WebSocketGateway(namespace: '/chat') export class ChatGateway {} uses invalid syntax. @WebSocketGateway({ path: '/chat' }) export class ChatGateway {} uses path which is not the correct key for namespace.

3. Final Answer:

   @WebSocketGateway({ namespace: '/chat' }) export class ChatGateway {} -> Option C

4. Quick Check:

   Use options object with namespace key [OK]

Hint: Use options object with namespace key for custom namespace [OK]

Common Mistakes:

• Passing namespace as a direct string argument
• Using invalid syntax inside decorator
• Confusing 'path' with 'namespace'

3.

Given the following code, what will be the output when a client connects?

@WebSocketGateway()
export class MyGateway {
  handleConnection(client: any) {
    console.log('Client connected');
  }
}

medium

A. Nothing happens because handleConnection is not called automatically

B. The server crashes due to missing WebSocket server initialization

C. An error occurs because handleConnection is missing a decorator

D. The message 'Client connected' is logged to the console when a client connects

Solution

1. Step 1: Understand handleConnection behavior

   In NestJS WebSocket gateways, handleConnection is a lifecycle method called automatically when a client connects.

2. Step 2: Analyze the code output

   The method logs 'Client connected' to the console, so this message appears on each client connection.

3. Final Answer:

   The message 'Client connected' is logged to the console when a client connects -> Option D

4. Quick Check:

   handleConnection logs message on client connect [OK]

Hint: handleConnection runs automatically on client connect [OK]

Common Mistakes:

• Thinking handleConnection needs a decorator
• Assuming no output without explicit event listener
• Believing server crashes without manual init

4.

Identify the error in this WebSocket gateway code:

@WebSocketGateway()
export class AppGateway {
  @SubscribeMessage('message')
  handleMessage(client, payload) {
    client.emit('message', payload);
  }
}

medium

A. The client object does not have an emit method; it should use client.send

B. The method handleMessage should return the payload instead of emitting

C. The @SubscribeMessage decorator is missing parentheses

D. The method handleMessage must be async

Solution

1. Step 1: Understand @SubscribeMessage handler behavior

   In NestJS, message handlers should return the response payload, not emit directly on the client.

2. Step 2: Analyze the code's client.emit usage

   Calling client.emit is incorrect; the framework handles sending the return value automatically.

3. Final Answer:

   The method handleMessage should return the payload instead of emitting -> Option B

4. Quick Check:

   Return payload in handler, don't emit manually [OK]

Hint: Return data in handler; don't call client.emit manually [OK]

Common Mistakes:

• Calling client.emit instead of returning data
• Thinking @SubscribeMessage needs parentheses
• Assuming handler must be async always

5.

You want to create a WebSocket gateway that listens on port 8081 and uses the namespace /notifications. Which of the following is the correct way to define this gateway?

hard

A. @WebSocketGateway({ port: 8081, namespace: '/notifications' })
export class NotificationGateway {}

B. @WebSocketGateway('/notifications', 8081)
export class NotificationGateway {}

C. @WebSocketGateway({ port: 8081 })
@WebSocketGateway({ namespace: '/notifications' })
export class NotificationGateway {}

D. @WebSocketGateway(8081, { namespace: '/notifications' })
export class NotificationGateway {}

Solution

1. Step 1: Recall the correct options object usage

   The @WebSocketGateway() decorator accepts a single options object where you can specify both port and namespace.

2. Step 2: Evaluate each option

   @WebSocketGateway({ port: 8081, namespace: '/notifications' }) export class NotificationGateway {} correctly passes an object with both port and namespace. @WebSocketGateway(8081, { namespace: '/notifications' }) export class NotificationGateway {} incorrectly uses positional arguments mixing number and object. @WebSocketGateway({ port: 8081 }) @WebSocketGateway({ namespace: '/notifications' }) export class NotificationGateway {} uses two decorators which is invalid. @WebSocketGateway('/notifications', 8081) export class NotificationGateway {} uses positional arguments in wrong order and types.

3. Final Answer:

   @WebSocketGateway({ port: 8081, namespace: '/notifications' }) export class NotificationGateway {} -> Option A

4. Quick Check:

   Use single options object for port and namespace [OK]

Hint: Use one options object with port and namespace keys [OK]

Common Mistakes:

• Passing port and namespace as separate arguments
• Using multiple @WebSocketGateway decorators
• Mixing argument types and order incorrectly