What are DTOs in NestJS?

Question

Accepted Answer

A **DTO (Data Transfer Object)** is a class that defines the **shape of data** sent to or from your API — typically the structure of a request body. DTOs provide type safety, serve as a clear contract for endpoints, and (with validation decorators) enable automatic input validation.

## Defining a DTO

```ts
import { IsEmail, IsString, MinLength, IsOptional, IsInt, Min } from "class-validator";

export class CreateUserDto {
  @IsEmail()                    // must be a valid email
  email: string;

@IsString()
  @MinLength(8)                 // password at least 8 chars
  password: string;

@IsOptional()                 // optional field
  @IsInt()
  @Min(0)
  age?: number;
}
```

A DTO is a plain class describing the expected data, with **validation decorators** (from `class-validator`) specifying the rules each field must satisfy.

## Using a DTO in a controller

```ts
@Post()
create(@Body() dto: CreateUserDto) {     // the body is typed AND validated as CreateUserDto
  // dto is guaranteed to be valid here (with the validation pipe enabled)
  return this.usersService.create(dto);
}
```

The `@Body() dto: CreateUserDto` types the request body and — with the validation pipe enabled — automatically validates it before your handler runs.

## Enabling automatic validation

```ts
// main.ts — turn on the global validation pipe
app.useGlobalPipes(new ValidationPipe({
  whitelist: true,              // strip properties NOT in the DTO (security)
  forbidNonWhitelisted: true,   // reject requests with extra unknown properties
  transform: true,              // auto-transform payloads to DTO instances + convert types
}));
```

With the `ValidationPipe`, NestJS validates incoming bodies against the DTO's decorators automatically — returning a 400 error with details if validation fails, before your code runs.

## DTOs vs Entities

```text
DTO    → the shape of data crossing the API boundary (request/response contract)
Entity → the database model (e.g. a TypeORM entity / Prisma model)
→ Keep them SEPARATE: the API contract shouldn't be coupled to the DB schema.
  (A CreateUserDto has password+email; the User entity has id, timestamps, etc.)
```

DTOs deliberately differ from database entities — they represent what the API accepts/returns, decoupled from internal storage.

## Variations and reuse

```ts
import { PartialType } from "@nestjs/mapped-types";
// derive an UpdateUserDto where all fields are optional — no duplication
export class UpdateUserDto extends PartialType(CreateUserDto) {}
```

## Why it matters

DTOs are an important NestJS pattern that brings type safety, clear API contracts, and automatic validation to your endpoints.

They define exactly what data an endpoint accepts (the request shape), giving you compile-time typing and serving as self-documenting contracts.

Crucially, combined with `class-validator` decorators and the `ValidationPipe`, they enable **automatic input validation** — malformed or malicious requests are rejected with clear errors *before* reaching your business logic, which is essential for security and robustness (the `whitelist` option also strips unexpected properties).

Understanding DTOs, how to add validation rules, how to enable the validation pipe, and the important principle of **keeping DTOs separate from database entities** (decoupling the API contract from internal storage) is fundamental for building safe, well-structured, maintainable NestJS APIs.

DTOs appear in virtually every endpoint that accepts input, making them everyday, essential knowledge.