Why DTOs enforce data contracts in NestJS

Introduction

DTOs help make sure the data sent and received in your app is clear and correct. They act like a simple agreement on what data should look like.

When you want to check that user input has the right shape before using it.

When sending data between different parts of your app to keep things organized.

When you want to avoid errors caused by missing or wrong data fields.

When you want to clearly document what data your app expects or sends.

When you want to make your app easier to test and maintain.

Syntax

NestJS

export class CreateUserDto {
  readonly name: string;
  readonly age: number;
}

DTOs are usually simple classes with properties but no methods.

Use TypeScript types to define what data is expected.

Examples

This DTO defines the data needed to log in a user.

NestJS

export class LoginDto {
  readonly email: string;
  readonly password: string;
}

Optional fields can be marked with ? to allow partial updates.

NestJS

export class UpdateProfileDto {
  readonly bio?: string;
  readonly avatarUrl?: string;
}

Sample Program

This example shows a DTO with validation decorators to enforce data types and rules. The controller uses the DTO to accept and validate user data.

NestJS

import { IsString, IsInt, Min } from 'class-validator';

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

  @IsInt()
  @Min(0)
  readonly age: number;
}

// Example usage in a NestJS controller
import { Controller, Post, Body } from '@nestjs/common';

@Controller('users')
export class UsersController {
  @Post()
  createUser(@Body() createUserDto: CreateUserDto) {
    return `User ${createUserDto.name} aged ${createUserDto.age} created`;
  }
}

Important Notes

DTOs help catch errors early by validating data before using it.

Use libraries like class-validator with DTOs for automatic checks.

DTOs improve code readability and teamwork by clearly showing data expectations.

Summary

DTOs define clear data shapes to avoid mistakes.

They help validate and organize data in NestJS apps.

Using DTOs makes your code safer and easier to understand.

Practice

1. Why do we use DTOs (Data Transfer Objects) in NestJS applications?

easy

A. To speed up the application runtime

B. To handle user interface styling

C. To replace database models completely

D. To define clear data shapes and enforce data contracts

Solution

1. Step 1: Understand the purpose of DTOs

   DTOs are used to define the shape and structure of data that travels through the application.

2. Step 2: Identify the main benefit in NestJS context

   They enforce data contracts, meaning they ensure data is consistent and validated before use.

3. Final Answer:

   To define clear data shapes and enforce data contracts -> Option D

4. Quick Check:

   DTOs = enforce data contracts [OK]

Hint: DTOs define data shape and rules clearly [OK]

Common Mistakes:

• Thinking DTOs speed up runtime
• Confusing DTOs with UI styling
• Assuming DTOs replace database models

2. Which of the following is the correct way to define a simple DTO class in NestJS using TypeScript?

easy

A. interface CreateUserDto { name: string; age: number; }

B. class CreateUserDto { name: string; age: number; }

C. function CreateUserDto() { return { name: string, age: number }; }

D. const CreateUserDto = { name: 'string', age: 'number' };

Solution

1. Step 1: Recall NestJS DTO syntax

   DTOs are usually defined as classes with typed properties in TypeScript.

2. Step 2: Check each option's syntax

   class CreateUserDto { name: string; age: number; } correctly defines a class with typed properties. function CreateUserDto() { return { name: string, age: number }; } is a function, not a class. interface CreateUserDto { name: string; age: number; } is an interface, which can't be used for runtime validation. const CreateUserDto = { name: 'string', age: 'number' }; is an object literal with string values, not types.

3. Final Answer:

   class CreateUserDto { name: string; age: number; } -> Option B

4. Quick Check:

   DTO = class with typed properties [OK]

Hint: DTOs are classes with typed properties in NestJS [OK]

Common Mistakes:

• Using interfaces instead of classes for DTOs
• Defining DTOs as plain objects
• Using functions instead of classes

3. Given this DTO and controller snippet, what will happen if the incoming request body misses the email property?

class RegisterDto {
  username: string;
  email: string;
}

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

medium

A. The server will crash with a runtime error

B. The request will succeed and email will be undefined

C. The request will fail validation if validation pipes are used

D. The missing property will be automatically filled with an empty string

Solution

1. Step 1: Understand DTO role with validation

   DTOs define expected data shape. If validation pipes are enabled, missing required properties cause validation errors.

2. Step 2: Analyze behavior when email is missing

   Without email, validation fails and the request is rejected. If no validation, email would be undefined, but NestJS commonly uses validation pipes.

3. Final Answer:

   The request will fail validation if validation pipes are used -> Option C

4. Quick Check:

   Missing required DTO property = validation error [OK]

Hint: Missing required DTO fields cause validation errors if pipes used [OK]

Common Mistakes:

• Assuming missing fields auto-fill with defaults
• Thinking server crashes on missing fields
• Ignoring validation pipes effect

4. Identify the error in this DTO usage that causes the validation to always pass even when data is invalid:

class UpdateProfileDto {
  name?: string;
  age?: number;
}

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

medium

A. DTO properties are optional, so validation does not enforce presence

B. DTO class is missing the @Injectable decorator

C. The controller method should use @Query instead of @Body

D. The DTO class must extend a base validation class

Solution

1. Step 1: Review DTO property optionality

   Properties marked with ? are optional, so validation allows them to be missing.

2. Step 2: Understand validation effect

   Because all properties are optional, invalid or missing data passes validation, which may be unintended.

3. Final Answer:

   DTO properties are optional, so validation does not enforce presence -> Option A

4. Quick Check:

   Optional DTO fields = no required validation [OK]

Hint: Optional properties skip required validation [OK]

Common Mistakes:

• Thinking @Injectable is needed on DTOs
• Confusing @Body with @Query usage
• Assuming inheritance is required for validation

5. You want to ensure that a DTO enforces that the password field is always a string with at least 8 characters. Which approach best enforces this contract in NestJS?

hard

A. Use class-validator decorators like @IsString() and @MinLength(8) on the password property

B. Manually check the password length inside the controller method

C. Define password: string in the DTO without decorators

D. Use a plain JavaScript object instead of a class for the DTO

Solution

1. Step 1: Understand validation decorators in NestJS

   Using class-validator decorators on DTO properties enforces rules automatically during validation.

2. Step 2: Compare options for enforcing password rules

   Use class-validator decorators like @IsString() and @MinLength(8) on the password property uses decorators to enforce string type and minimum length. Manually check the password length inside the controller method requires manual checks, which is less clean. Define password: string in the DTO without decorators lacks validation. Use a plain JavaScript object instead of a class for the DTO loses type safety and validation.

3. Final Answer:

   Use class-validator decorators like @IsString() and @MinLength(8) on the password property -> Option A

4. Quick Check:

   Validation decorators enforce data contracts best [OK]

Hint: Use validation decorators on DTO properties [OK]

Common Mistakes:

• Relying on manual validation in controllers
• Skipping decorators and trusting types only
• Using plain objects instead of classes