Why DTOs enforce data contracts in NestJS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why do DTOs help maintain consistent data in NestJS?

In NestJS, Data Transfer Objects (DTOs) are used to define the shape of data sent between client and server. Why does using DTOs help enforce data contracts?

A DTOs automatically encrypt data to secure it during transfer.

B DTOs define a fixed structure that incoming data must match, preventing unexpected or missing fields.

C DTOs allow any data shape, so developers can send flexible data without restrictions.

D DTOs replace the need for database models by storing data directly.

💡 Hint

Think about how defining a shape or schema helps catch errors early.

DTOs specify exactly what data is expected, so if data is missing or has extra fields, NestJS can catch it. This keeps data consistent and predictable.

❓ component_behavior

intermediate

What happens when invalid data is sent to a NestJS controller expecting a DTO?

Consider a NestJS controller method that expects a DTO with a required name string property. What will happen if the client sends a request missing the name field?

NestJS

import { IsString } from 'class-validator';

export class CreateUserDto {
  @IsString()
  name: string;
}

@Post()
createUser(@Body() createUserDto: CreateUserDto) {
  return `User ${createUserDto.name} created`;
}

A NestJS will crash the server with an unhandled exception.

B NestJS will accept the request and create a user with an undefined name.

C NestJS will ignore the missing field and fill it with an empty string.

D NestJS will throw a validation error and respond with a 400 Bad Request.

💡 Hint

Think about how validation pipes work with DTOs in NestJS.

When validation pipes are used, NestJS checks the incoming data against the DTO. Missing required fields cause a 400 error response.

📝 Syntax

advanced

Which DTO definition correctly enforces a required string and optional number in NestJS?

Choose the correct DTO class that enforces title as a required string and count as an optional number.

A

import { IsString, IsNumber, IsOptional } from 'class-validator';

export class ItemDto {
  @IsString()
  title: string;

  @IsNumber()
  @IsOptional()
  count?: number;
}

B

export class ItemDto {
  title?: string;
  count: number;
}

C

export class ItemDto {
  @IsNumber()
  title: number;

  @IsString()
  count?: string;
}

D

export class ItemDto {
  @IsOptional()
  title: string;

  count: number;
}

💡 Hint

Look for correct use of decorators and optional property syntax.

Option A uses @IsString() for required title and @IsOptional() with @IsNumber() for optional count. Others have wrong types or missing decorators.

🔧 Debug

advanced

Why does this DTO validation not reject missing fields?

Given this DTO and controller, why does NestJS accept requests missing the email field?

NestJS

import { IsEmail, IsString } from 'class-validator';

export class RegisterDto {
  @IsEmail()
  email: string;

  @IsString()
  password: string;
}

@Post('register')
register(@Body() registerDto: RegisterDto) {
  return 'Registered';
}

A The ValidationPipe is not enabled globally or on the route, so validation is skipped.

B The <code>@IsEmail()</code> decorator is incorrect and does not validate the field.

C The <code>email</code> property is optional by default, so missing is allowed.

D NestJS does not support validation on DTOs without explicit type annotations.

💡 Hint

Think about how validation is triggered in NestJS.

Validation decorators only work if ValidationPipe is enabled. Without it, DTOs are just plain classes and no validation happens.

❓ state_output

expert

What is the output when sending extra fields not in the DTO with ValidationPipe whitelist enabled?

Consider this DTO and controller with ValidationPipe configured with whitelist: true. What will the response contain if the client sends extra fields?

NestJS

import { IsString } from 'class-validator';

export class UpdateProfileDto {
  @IsString()
  username: string;
}

@Post('update')
updateProfile(@Body() updateProfileDto: UpdateProfileDto) {
  return updateProfileDto;
}

// ValidationPipe setup:
// app.useGlobalPipes(new ValidationPipe({ whitelist: true }));

A Server crashes due to unexpected fields in the DTO.

B {"username":"newuser", "age":30} - extra fields are kept in the object.

C {"username":"newuser"} - extra fields are removed from the object.

D Validation error response because extra fields are not allowed.

💡 Hint

What does the whitelist option do in ValidationPipe?

With whitelist: true, ValidationPipe strips out any properties not defined in the DTO before passing the object to the controller.