class-validator decorators in NestJS - Performance & Optimization

Performance: class-validator decorators

MEDIUM IMPACT

This affects the server-side validation step before data processing, impacting request handling speed and response time.

Validating user input data in a NestJS DTO

NestJS

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

export class UserDto {
  @IsString()
  @Length(5, 50)
  username: string;

  @IsInt()
  @Min(0)
  @Max(150)
  age: number;

  @IsString()
  @Length(0, 255)
  bio: string;

  // Removed description field to reduce validation overhead
}

Reducing the number of validated fields and simplifying decorators lowers CPU time spent validating each request.

📈 Performance GainReduces validation time by up to 50%, improving request throughput

Validating user input data in a NestJS DTO

NestJS

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

export class UserDto {
  @IsString()
  @Length(5, 50)
  username: string;

  @IsInt()
  @Min(0)
  @Max(150)
  age: number;

  @IsString()
  @Length(0, 255)
  bio: string;

  @IsString()
  @Length(0, 1000)
  description: string;
}

Applying many decorators with complex validation logic on large DTOs causes slower validation and higher CPU usage per request.

📉 Performance CostBlocks request processing for 10-30ms depending on DTO size and complexity

Performance Comparison

Pattern	Validation CPU Cost	Request Latency Impact	Memory Usage	Verdict
Many complex decorators on large DTO	High CPU usage	Adds 10-30ms latency	Moderate	[X] Bad
Minimal decorators on essential fields	Low CPU usage	Adds 2-5ms latency	Low	[OK] Good

Rendering Pipeline

Class-validator decorators run on the server before rendering or responding. They do not affect browser rendering but impact server response time.

→Request Validation

→Request Processing

⚠️ BottleneckValidation CPU time increases with decorator complexity and DTO size

Optimization Tips

1Use only necessary class-validator decorators to reduce validation CPU cost.

2Avoid complex or custom validators on large DTOs to keep request latency low.

3Measure validation time in development to identify and optimize slow validations.

Performance Quiz - 3 Questions

How do many class-validator decorators affect NestJS request handling?

A They improve browser rendering speed

B They reduce server memory usage

C They increase CPU time and delay response

D They decrease network latency

DevTools: Node.js Profiler or NestJS Debug Logs

How to check: Run your NestJS app with profiling enabled or add timing logs around validation calls to measure validation duration per request.

What to look for: Look for long validation times or CPU spikes during request handling indicating expensive validation

Practice

1. What is the main purpose of @IsEmail() decorator in class-validator when used in a NestJS DTO class?

easy

A. To convert the property value to lowercase

B. To check if the property value is a valid email address format

C. To make the property optional

D. To trim whitespace from the property value

Solution

1. Step 1: Understand the decorator's role

   The @IsEmail() decorator validates that the decorated property contains a valid email format string.

2. Step 2: Compare options with decorator behavior

   Only To check if the property value is a valid email address format matches the validation purpose of @IsEmail(). Other options describe unrelated behaviors.

3. Final Answer:

   To check if the property value is a valid email address format -> Option B

4. Quick Check:

   @IsEmail() validates email format [OK]

Hint: Remember: @IsEmail() checks email format only [OK]

Common Mistakes:

• Thinking @IsEmail() modifies the value instead of validating
• Confusing @IsEmail() with @IsOptional() or @Transform decorators

2. Which of the following is the correct way to use @Length() decorator to require a string property to be between 5 and 10 characters in NestJS?

easy

A. @Length(5, 10)

B. @Length(10, 5)

C. @Length(min=5, max=10)

D. @Length({min:5, max:10})

Solution

1. Step 1: Recall the syntax of @Length decorator

   The @Length() decorator takes two numeric arguments: minimum length first, then maximum length.

2. Step 2: Match options with correct syntax

   @Length(5, 10) correctly uses @Length(5, 10). Options A, B, and D use incorrect argument order or syntax.

3. Final Answer:

   @Length(5, 10) -> Option A

4. Quick Check:

   @Length(min, max) = @Length(5, 10) [OK]

Hint: @Length(min, max) uses two numbers, min first [OK]

Common Mistakes:

• Swapping min and max values
• Using object syntax instead of positional arguments
• Using named parameters which are invalid

3. Given this DTO class, what will be the validation result for username = 'abc' and age = 17?

class UserDto {
  @Length(5, 15)
  username: string;

  @Min(18)
  age: number;
}

medium

A. Validation passes with no errors

B. Validation fails because username is too short

C. Validation fails because age is less than 18

D. Validation fails because both username and age are invalid

Solution

1. Step 1: Check username length

   The username 'abc' has length 3, which is less than the minimum 5 required by @Length(5, 15). So username is invalid.

2. Step 2: Check age minimum

   The age is 17, which is less than the minimum 18 required by @Min(18). So age is invalid.

3. Final Answer:

   Validation fails because both username and age are invalid -> Option D

4. Quick Check:

   username too short + age too low = both invalid [OK]

Hint: Check each decorator rule separately for all properties [OK]

Common Mistakes:

• Ignoring one invalid field and assuming validation passes
• Confusing @Min with @Max for age
• Assuming length includes spaces or trimming automatically

4. Identify the error in this DTO class using class-validator decorators:

class ProductDto {
  @IsInt()
  @Min(1)
  price: string;
}

medium

A. price should be a number type, not string

B. Missing @IsString() decorator for price

C. @Min(1) cannot be used with @IsInt()

D. No error, code is correct

Solution

1. Step 1: Analyze property type and decorators

   The property price is declared as string, but decorators @IsInt() and @Min(1) expect a number type.

2. Step 2: Identify mismatch causing validation error

   Since price is string, validation will fail because @IsInt() requires a number. The type should be number.

3. Final Answer:

   price should be a number type, not string -> Option A

4. Quick Check:

   Type mismatch between property and decorators = error [OK]

Hint: Match property type with decorator expectations [OK]

Common Mistakes:

• Using string type with number validators
• Assuming decorators convert types automatically
• Ignoring TypeScript type declarations

5. You want to validate a DTO property tags which is an array of strings, each string must be at least 3 characters. Which combination of class-validator decorators correctly enforces this?

hard

A. @IsString()\n@Length(3, 50)\n@IsArray()

B. @IsArray()\n@IsString()\n@Length(3, 50)

C. @IsArray()\n@ArrayMinSize(1)\n@IsString({ each: true })\n@Length(3, 50, { each: true })

D. @IsArray()\n@ArrayMaxSize(1)\n@IsString({ each: false })

Solution

1. Step 1: Validate the property is an array

   Use @IsArray() to ensure tags is an array type.

2. Step 2: Validate each element is a string with length constraints

   Use @IsString({ each: true }) and @Length(3, 50, { each: true }) to apply string and length validation to every item in the array.

3. Step 3: Ensure array has at least one element

   @ArrayMinSize(1) ensures the array is not empty.

4. Final Answer:

   @IsArray()\n@ArrayMinSize(1)\n@IsString({ each: true })\n@Length(3, 50, { each: true }) -> Option C

5. Quick Check:

   Array + each:true for element validation = @IsArray()\n@ArrayMinSize(1)\n@IsString({ each: true })\n@Length(3, 50, { each: true }) [OK]

Hint: Use { each: true } to validate every array element [OK]

Common Mistakes:

• Forgetting { each: true } for array element validation
• Using @IsString() without array context
• Setting wrong array size constraints