Standardizing Data Input with DTOs in NestJS

Introduction

In the crm-saas-backend project, we are focusing on improving the maintainability of our CRM follow-up system. As our application scales, managing incoming request data becomes critical to ensure data integrity and API clarity. To address this, we are moving toward a strictly typed Data Transfer Object (DTO) pattern using NestJS and Swagger.

The Challenge of Unstructured Payloads

Previously, handling request bodies meant relying on implicit types or unstructured objects. This approach often leads to runtime errors and makes API documentation difficult to maintain. By implementing DTOs, we centralize our data requirements in one place.

Implementing DTOs for Follow-ups

We define our follow-up structures using TypeScript classes. This allows us to enforce constraints and annotate our API endpoints for automated documentation generation.

import { ApiProperty } from '@nestjs/swagger';
import { IsString, IsNotEmpty, IsDateString } from 'class-validator';

export class CreateFollowUpDto {
  @ApiProperty({ description: 'The identifier for the user' })
  @IsString()
  @IsNotEmpty()
  userId: string;

  @ApiProperty({ description: 'Details of the interaction' })
  @IsString()
  notes: string;

  @ApiProperty({ description: 'Scheduled date' })
  @IsDateString()
  followUpDate: string;
}

This DTO serves two purposes: it provides a schema for class-validator to sanitize input, and it provides metadata for Swagger to generate accurate API documentation automatically.

Benefits of This Approach

By leveraging the NestJS validation pipe, we ensure that incoming requests are automatically rejected if they do not match our DTO definitions. Furthermore, since we use ApiProperty decorators, our Swagger UI remains perfectly synced with our internal data structures without manual intervention.

Conclusion

Adopting DTOs has streamlined our input processing and API definition. If you are working on a NestJS application, ensure that you define your DTOs early in the feature development cycle to avoid manual validation bloat. As a next step, consider extending these classes to share validation logic across related modules.

Generated with Gitvlg.com