NestJS Do's and Don'ts

Do These Things

Do register providers in modules. Do validate DTOs. Do inject dependencies via constructors. Do keep business logic in services. Do use ConfigService for secrets. Do write tests for critical flows.

// DO
constructor(private readonly usersService: UsersService) {}

// DON'T
const usersService = new UsersService(new UsersRepository());

Manual new bypasses Nest DI, lifecycle hooks, and easy mocking.

Don't Do These Things

- Don't put DB queries in controllers
- Don't trust client input without ValidationPipe
- Don't commit secrets
- Don't use synchronize:true in production
- Don't ignore shutdown hooks in containers
- Don't catch and swallow errors silently

• Do prefer explicit imports/exports over hidden globals.
• Don't create circular modules casually—refactor ownership.
• Do use guards for auth; don't duplicate token checks in every method.
• Don't return raw ORM entities with sensitive fields.

Do / Don't Cheatsheet

Fast reference reminders.

Pragmatism

Rules have exceptions. A tiny internal tool may skip some ceremony. Production multi-tenant APIs should not.

Code Review Lens

In PR review, check module wiring, validation, auth guards on new routes, and tests for failure paths.

Common Mistakes

• Treating this list as optional after the demo day.
• Cargo-culting every Nest pattern into a 200-line script.
• Ignoring secure defaults because "we'll add them later".

Key Takeaways

• Prefer DI, validation, and feature modules.
• Avoid bypassing Nest abstractions in feature code.
• Never ship secrets or auto-sync schema to production.
• Use do/don't lists during reviews to catch regressions.