Standardize DTO validation: enable global ValidationPipe and annotate DTOs with class-validator

[memplethee-lab]

Summary

What: Implement a robust request/response validation layer and standardize DTOs with class-validator/class-transformer across the codebase.
Why: Reduces runtime errors, improves API reliability, and provides consistent developer experience.
Which part: DTOs, controllers, global pipes, and tests.

Problem Statement

Current limitation

• Some DTOs are missing validation decorators; global ValidationPipe may not be applied consistently.
• Inconsistent DTO structure increases risk of runtime errors and inconsistent API contracts.

Pain point

• Developers and clients receive unclear errors; tests may be flaky due to missing input validation.

Why it matters

• Proper validation improves API safety, developer productivity, and reduces potential security issues.

Proposed Solution

How it should work

• Audit all DTOs under src/**/dto and ensure they use class-validator and class-transformer decorators.
• Enforce a global ValidationPipe in src/main.ts with whitelist, forbidNonWhitelisted, and transform options.
• Add unit tests for controllers to validate input rejection/acceptance.

Expected behavior

• All incoming requests are validated and transformed to DTO instances.
• Controllers throw clear validation errors with HTTP 400 and structured messages.

Important notes

• Start with public API DTOs; prioritize portfolio, auth, and investment modules.

Implementation Guidance

Files/folders likely affected

• src/main.ts
• src//dto//*.ts
• test/** (add validation tests)

Modules/Services involved

• Global bootstrap (ValidationPipe)
• DTOs and controllers

Dependencies/prerequisites

• class-validator, class-transformer (already in package.json or add), jest tests

Suggested steps

1. Add or update global ValidationPipe in src/main.ts.
2. Add missing decorators to DTOs: @IsString, @isnumber, @IsUUID, etc.
3. Add tests verifying validation.
4. Update README with validation conventions.

Acceptance Criteria

Acceptance Criteria

• Global ValidationPipe enabled with whitelist and transform
• All public DTOs updated with class-validator decorators
• Unit tests added for validation behavior
• Documentation updated with DTO/validation conventions
• Feature passes linting and existing CI checks

Technical Notes

API changes

• Responses unchanged; request payloads will be validated more strictly, which may break bad clients.
  Database changes
• None.
  Security
• Reduces injection and malformed payload attacks.
  Performance
• Minor overhead for validation; acceptable for API servers.
  Accessibility
• Validation errors should be clear and machine-readable.
  Edge cases
• Backwards compatibility: consider a migration strategy to avoid breaking clients.

Definition of Done

• All acceptance criteria met
• Tests added and passing
• README updated

Labels

• enhancement, backend, api, documentation

Priority

• High

Estimated Difficulty

• Intermediate

Estimated Effort

• M