Why DTOs enforce data contracts in NestJS - Visual Breakdown

Concept Flow - Why DTOs enforce data contracts

Client sends data

↓

DTO receives data

↓

Validation checks data shape

Yes No↓

Data passes

↓

Service uses data safely

Data flows from client to DTO, which checks if data matches the expected shape. If valid, service uses it; if not, error is returned.

Execution Sample

NestJS

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

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

  @IsEmail()
  email: string;
}

Defines a DTO class that enforces 'name' as string and 'email' as valid email format.

Execution Table

Step	Input Data	Validation Check	Result	Action Taken
1	{"name": "Alice", "email": "[e-mail]"}	name is string, email is valid email	Pass	Data accepted, passed to service
2	{"name": 123, "email": "[e-mail]"}	name is string (fails)	Fail	Error returned: name must be string
3	{"name": "Bob", "email": "not-an-email"}	email is valid email (fails)	Fail	Error returned: email must be valid
4	{"name": "Carol"}	email is present and valid (fails)	Fail	Error returned: email missing or invalid

💡 Execution stops when validation fails or data passes and moves to service.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4
inputData	{}	{"name": "Alice", "email": "[e-mail]"}	{"name": 123, "email": "[e-mail]"}	{"name": "Bob", "email": "not-an-email"}	{"name": "Carol"}
validationResult	null	Pass	Fail	Fail	Fail

Key Moments - 2 Insights

Why does the DTO reject data if a field is missing or wrong type?

The DTO enforces a contract that data must match expected types and presence. As shown in execution_table rows 2-4, validation fails if data is missing or wrong type, preventing unsafe data usage.

What happens if data passes validation?

When data passes validation (row 1), it is safely passed to the service layer, ensuring the service can rely on the data shape and types.

Visual Quiz - 3 Questions

Look at the execution table, what is the validation result at step 3?

A Pass

B Error

C Fail

D Skipped

💡 Hint

Check the 'Validation Check' and 'Result' columns at step 3 in the execution_table.

At which step does the input data have a missing email field?

A Step 4

B Step 2

C Step 1

D Step 3

💡 Hint

Look at the 'Input Data' column for missing 'email' key in execution_table.

If the 'name' field was optional, how would the validation result change at step 2?

A It would pass validation

B It would still fail validation

C It would cause a runtime error

D It would skip validation

💡 Hint

Refer to variable_tracker and execution_table rows where 'name' type causes failure.

Concept Snapshot

DTOs (Data Transfer Objects) define expected data shapes.
They enforce contracts by validating incoming data.
If data matches, it passes to service safely.
If not, validation errors stop processing.
This prevents bugs and security issues.
Use decorators like @IsString() and @IsEmail() in NestJS.

Full Transcript

In NestJS, DTOs enforce data contracts by defining the expected shape and types of data using classes and decorators. When data arrives from a client, it is checked against the DTO. If the data matches the expected types and required fields, it passes validation and is safely used by the service. If the data is missing fields or has wrong types, validation fails and an error is returned. This process ensures that the application only works with safe, predictable data, preventing bugs and security problems. The execution table shows examples of data passing and failing validation, illustrating how DTOs enforce these contracts step-by-step.

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