WebSocket guards and pipes in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a WebSocket guard denies access?

In a NestJS WebSocket gateway, if a guard returns false, what is the immediate effect on the client connection or message handling?

A The client connection is immediately closed by the server.

B The server throws an exception and disconnects the client.

C The message is ignored and not processed, but the connection stays open.

D The guard result is ignored and the message is processed anyway.

💡 Hint

Think about how guards control message flow without forcibly closing connections.

When a WebSocket guard returns false, NestJS prevents the message handler from running but keeps the connection alive. It does not close the connection or throw errors automatically.

📝 Syntax

intermediate

Identify the correct way to apply a pipe to a WebSocket message handler

Which of the following code snippets correctly applies a pipe to transform incoming WebSocket message data in NestJS?

NestJS

import { SubscribeMessage, WebSocketGateway, MessageBody } from '@nestjs/websockets';
import { UsePipes, ValidationPipe } from '@nestjs/common';

@WebSocketGateway()
export class ChatGateway {
  @SubscribeMessage('message')
  @UsePipes(new ValidationPipe())
  handleMessage(@MessageBody() data: any) {
    return data;
  }
}

A @UsePipes(new ValidationPipe()) placed above the @SubscribeMessage decorator.

B @UsePipes(new ValidationPipe()) placed below the @SubscribeMessage decorator and above the method.

C Passing the pipe instance directly as a parameter to @SubscribeMessage decorator.

D Applying the pipe inside the method body manually.

💡 Hint

Look at the decorator order NestJS expects for pipes on handlers.

The @UsePipes decorator must be placed directly above the method it affects, after the @SubscribeMessage decorator. Passing pipes as parameters or applying them inside the method is not the NestJS pattern.

🔧 Debug

advanced

Why does this WebSocket guard not block unauthorized users?

Consider this guard code for a NestJS WebSocket gateway: ```typescript import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common'; @Injectable() export class AuthGuard implements CanActivate { canActivate(context: ExecutionContext): boolean { const client = context.switchToWs().getClient(); if (client.handshake?.auth?.token === 'valid-token') { return true; } return false; } } ``` Why might this guard fail to block unauthorized users?

A The guard checks the token on the handshake object, but the token is sent in message data instead.

B The guard returns a boolean instead of a Promise<boolean>.

C The guard does not throw an exception on failure, so NestJS ignores the false return.

D The guard uses ExecutionContext instead of WsContext, causing context.switchToWs() to fail.

💡 Hint

Check where the token is expected versus where the guard looks for it.

The guard checks client.handshake.auth.token, but if the client sends the token inside the message payload instead, the guard will not find it and always return false or true incorrectly.

❓ state_output

advanced

What is the output after applying a custom pipe to transform WebSocket message data?

Given this custom pipe and WebSocket handler in NestJS: ```typescript import { PipeTransform, Injectable, ArgumentMetadata } from '@nestjs/common'; @Injectable() export class AppendPipe implements PipeTransform { transform(value: any, metadata: ArgumentMetadata) { return value + ' world'; } } @WebSocketGateway() export class HelloGateway { @SubscribeMessage('greet') @UsePipes(AppendPipe) handleGreet(@MessageBody() message: string) { return message; } } ``` If the client sends the message 'hello', what will the server return?

A Throws a runtime error because AppendPipe is not instantiated.

B 'hello'

C 'helloundefined world'

D 'hello world'

💡 Hint

Consider how pipes are applied and instantiated in NestJS decorators.

The pipe class AppendPipe is passed directly to @UsePipes without instantiation. NestJS expects an instance or a class reference, but for classes it creates instances automatically only if passed as a class reference without parentheses. Here, passing the class without parentheses is correct, but if the pipe requires constructor parameters or is not injectable, it will fail.

In this case, since AppendPipe is injectable and has no constructor parameters, NestJS will instantiate it. So the correct output is 'hello world'.

🧠 Conceptual

expert

Which statement about WebSocket guards and pipes in NestJS is true?

Select the one true statement about how guards and pipes work together in NestJS WebSocket gateways.

A Guards run before pipes, so access control happens before data transformation.

B Pipes run only if guards throw exceptions, otherwise they are skipped.

C Guards and pipes run simultaneously, so their order does not matter.

D Pipes run before guards, so data is transformed before access is checked.

💡 Hint

Think about the security flow: check access first, then transform data.

In NestJS, guards run first to decide if the request or message should proceed. Only if guards allow it do pipes run to transform or validate data before the handler executes.

Practice

1. What is the main purpose of a WebSocket guard in a NestJS application?

easy

A. To control access and decide if a client can connect or send messages

B. To transform incoming message data before it reaches the handler

C. To log all WebSocket messages for debugging

D. To automatically retry failed WebSocket connections

Solution

1. Step 1: Understand the role of guards

   Guards in NestJS are used to control access by allowing or denying client connections or message handling.

2. Step 2: Differentiate guards from pipes

   Pipes transform or validate data, not control access, so they do not decide connection permissions.

3. Final Answer:

   To control access and decide if a client can connect or send messages -> Option A

4. Quick Check:

   Guards control access = A [OK]

Hint: Guards control access, pipes transform data [OK]

Common Mistakes:

• Confusing guards with pipes
• Thinking guards transform data
• Assuming guards handle logging

2. Which of the following is the correct way to apply a guard to a WebSocket gateway method in NestJS?

easy

A. @UseGuards(MyGuard) on the gateway class

B. @UseGuards(MyGuard) on the gateway method

C. @UsePipes(MyGuard) on the gateway method

D. @UseFilters(MyGuard) on the gateway class

Solution

1. Step 1: Recall decorator usage for guards

   Guards are applied using @UseGuards decorator either on the class or method. Applying on method is valid and common.

2. Step 2: Identify correct decorator and target

   @UseGuards is correct for guards; @UsePipes is for pipes, and @UseFilters is for exception filters.

3. Final Answer:

   @UseGuards(MyGuard) on the gateway method -> Option B

4. Quick Check:

   @UseGuards on method = A [OK]

Hint: Use @UseGuards for guards, not pipes or filters [OK]

Common Mistakes:

• Using @UsePipes instead of @UseGuards for guards
• Applying filters instead of guards
• Applying decorators on wrong targets

3. Given this WebSocket gateway method with a pipe, what will happen if the incoming message payload is invalid?

@SubscribeMessage('msg')
@UsePipes(new ValidationPipe())
handleMessage(@MessageBody() data: CreateDto) {
  return 'Received';
}

medium

A. The server crashes due to invalid data

B. The message is accepted without validation

C. The message is rejected and an error is sent back to the client

D. The message is transformed but still processed

Solution

1. Step 1: Understand ValidationPipe behavior

   ValidationPipe checks incoming data and rejects it if invalid, sending an error response.

2. Step 2: Analyze the method setup

   The method uses @UsePipes with ValidationPipe, so invalid data triggers rejection, not acceptance or crash.

3. Final Answer:

   The message is rejected and an error is sent back to the client -> Option C

4. Quick Check:

   ValidationPipe rejects invalid data = C [OK]

Hint: ValidationPipe rejects invalid data automatically [OK]

Common Mistakes:

• Assuming invalid data is accepted
• Thinking server crashes on invalid data
• Confusing transformation with acceptance

4. Identify the error in this WebSocket gateway code snippet:

@SubscribeMessage('chat')
@UseGuards(AuthGuard)
@UsePipes(new ParseIntPipe())
handleChat(@MessageBody() data: string) {
  return data;
}

medium

A. handleChat method must return a Promise

B. AuthGuard cannot be used with WebSocket gateways

C. @UsePipes must be placed before @UseGuards

D. ParseIntPipe cannot parse a string directly without conversion

Solution

1. Step 1: Check pipe compatibility with data type

   ParseIntPipe expects a value that can be parsed to integer, but data is a string that may not convert properly.

2. Step 2: Validate other decorator usage

   AuthGuard is valid for WebSocket guards, and decorator order does not cause error here. Returning Promise is optional.

3. Final Answer:

   ParseIntPipe cannot parse a string directly without conversion -> Option D

4. Quick Check:

   ParseIntPipe needs numeric input = D [OK]

Hint: Pipes must match expected input types [OK]

Common Mistakes:

• Assuming guards can't be used on WebSocket
• Thinking decorator order always matters
• Believing return type must be Promise

5. You want to ensure only authenticated users can send messages and that the message payload is a valid JSON object with a 'text' property. Which combination of guard and pipe setup is best in a NestJS WebSocket gateway?

hard

A. Use @UseGuards(AuthGuard) to check authentication and @UsePipes(ValidationPipe) with a DTO validating 'text' property

B. Use @UsePipes(AuthGuard) to check authentication and @UseGuards(ValidationPipe) for payload validation

C. Use @UseGuards(AuthGuard) only, and validate payload manually inside the handler

D. Use @UsePipes(ValidationPipe) only, assuming it checks authentication too

Solution

1. Step 1: Assign correct roles to guard and pipe

   Guards handle authentication and authorization, so AuthGuard should be used as a guard.

2. Step 2: Use ValidationPipe with DTO for payload validation

   ValidationPipe validates and transforms incoming data using a DTO that checks the 'text' property.

3. Step 3: Evaluate other options

   Swapping guards and pipes misuses decorators; using guards only requires manual payload validation lacking automation; using pipes only misses authentication checks.

4. Final Answer:

   Use @UseGuards(AuthGuard) to check authentication and @UsePipes(ValidationPipe) with a DTO validating 'text' property -> Option A

5. Quick Check:

   Guard for auth + Pipe for validation = B [OK]

Hint: Guards for auth, pipes for data validation [OK]

Common Mistakes:

• Swapping guards and pipes roles
• Skipping automatic validation
• Assuming pipes handle authentication