nestjs-best-practices
giuseppe-trisciuoglio/developer-kit
Enforce modular NestJS architecture, DI scoping, validation, error handling, and Drizzle ORM patterns.
What is nestjs-best-practices?
A comprehensive guide to NestJS best practices covering modular architecture, dependency injection scoping, exception filters, DTO validation with class-validator, and Drizzle ORM integration. Use when designing NestJS modules, implementing providers, creating exception filters, validating DTOs, or integrating Drizzle ORM within NestJS applications.
- Enforce modular architecture with strict module encapsulation and domain-driven design
- Guide dependency injection scoping (DEFAULT, REQUEST, TRANSIENT) based on use case
- Standardize error handling with custom exception filters and domain-specific exceptions
- Validate all API inputs with class-validator decorators and global ValidationPipe
- Integrate Drizzle ORM following NestJS provider conventions and repository pattern
- Document the complete NestJS request lifecycle (Middleware → Guards → Interceptors → Pipes → Handlers → Filters)
How to install nestjs-best-practices
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill nestjs-best-practices- NestJS project already initialized
- Familiarity with TypeScript and decorators
- class-validator and class-transformer packages installed for DTO validation
How to use nestjs-best-practices
- 1.Review the modular architecture section to understand module encapsulation and when to use forwardRef()
- 2.Identify the correct DI scope (DEFAULT, REQUEST, or TRANSIENT) for each provider in your application
- 3.Implement a global ExceptionFilter and create domain-specific exception classes for error handling
- 4.Add class-validator decorators to all DTO properties and enable ValidationPipe globally with transform and whitelist options
- 5.Wrap your Drizzle ORM client in an injectable provider and implement the repository pattern for data access
- 6.Run the provided examples and reference files to validate your implementation against best practices
Use cases
- Designing or refactoring a NestJS module structure to enforce encapsulation and avoid circular dependencies
- Creating validated DTOs and implementing a global exception filter for consistent error responses
- Integrating Drizzle ORM as an injectable provider with repository pattern for data access
- Onboarding a team to a NestJS codebase by reviewing code against best practices
- Choosing the correct dependency injection scope (singleton vs. request vs. transient) for a new provider
- NestJS backend developers building scalable server applications
- Teams establishing architectural standards and code review guidelines for NestJS projects
- Developers integrating Drizzle ORM into existing NestJS applications
- Architects designing modular, domain-driven NestJS systems
nestjs-best-practices FAQ
Use REQUEST scope only when you need per-request isolation, such as storing tenant or user context that must not leak between requests. Default to DEFAULT (singleton) scope for stateless services and repositories.
Avoid forwardRef() as a first resort. Instead, restructure your modules to eliminate the circular dependency—extract shared logic into a separate module or reorganize domain boundaries.
class-validator decorators define validation rules on DTO properties. ValidationPipe is the global middleware that applies those rules to incoming requests. Both are required: decorators define rules, ValidationPipe enforces them.
Yes. Wrap Drizzle queries in repository classes injected as providers. This encapsulates database logic, makes testing easier, and keeps controllers focused on HTTP concerns.
Create domain-specific exception classes extending HttpException, implement a global ExceptionFilter to format responses consistently, and use the Result pattern for expected business failures that don't warrant exceptions.
Full instructions (SKILL.md)
Source of truth, from giuseppe-trisciuoglio/developer-kit.
name: nestjs-best-practices description: Provides comprehensive NestJS best practices including modular architecture, dependency injection scoping, exception filters, DTO validation with class-validator, and Drizzle ORM integration. Use when designing NestJS modules, implementing providers, creating exception filters, validating DTOs, or integrating Drizzle ORM within NestJS applications. allowed-tools: Read, Write, Edit, Glob, Grep, Bash
NestJS Best Practices
Overview
Grounded in the Official NestJS Documentation, this skill enforces modular architecture, dependency injection scoping, exception filters, DTO validation with class-validator, and Drizzle ORM integration patterns.
When to Use
- Designing/refactoring NestJS modules or dependency injection
- Creating exception filters, validating DTOs, or integrating Drizzle ORM
- Reviewing code for anti-patterns or onboarding to a NestJS codebase
Instructions
1. Modular Architecture
Follow strict module encapsulation. Each domain feature should be its own @Module():
- Export only what other modules need — keep internal providers private
- Use
forwardRef()only as a last resort for circular dependencies; prefer restructuring - Group related controllers, services, and repositories within the same module
- Use a
SharedModulefor cross-cutting concerns (logging, configuration, caching)
See references/arch-module-boundaries.md for enforcement rules.
2. Dependency Injection
Choose the correct provider scope based on use case:
| Scope | Lifecycle | Use Case |
|---|---|---|
DEFAULT | Singleton (shared) | Stateless services, repositories |
REQUEST | Per-request instance | Request-scoped data (tenant, user context) |
TRANSIENT | New instance per injection | Stateful utilities, per-consumer caches |
- Default to
DEFAULTscope — only useREQUESTorTRANSIENTwhen justified - Use constructor injection exclusively — avoid property injection
- Register custom providers with
useClass,useValue,useFactory, oruseExisting
See references/di-provider-scoping.md for enforcement rules.
3. Request Lifecycle
Understand and respect the NestJS request processing pipeline:
Middleware → Guards → Interceptors (before) → Pipes → Route Handler → Interceptors (after) → Exception Filters
- Middleware: Cross-cutting concerns (logging, CORS, body parsing)
- Guards: Authorization and authentication checks (return
true/false) - Interceptors: Transform response data, add caching, measure timing
- Pipes: Validate and transform input parameters
- Exception Filters: Catch and format error responses
4. Error Handling
Standardize error responses across the application:
- Extend
HttpExceptionfor HTTP-specific errors - Create domain-specific exception classes (e.g.,
OrderNotFoundException) - Implement a global
ExceptionFilterfor consistent error formatting - Use the Result pattern for expected business logic failures
- Never silently swallow exceptions
See references/error-exception-filters.md for enforcement rules.
5. Validation
Enforce input validation at the API boundary:
- Enable
ValidationPipeglobally withtransform: trueandwhitelist: true - Decorate all DTO properties with
class-validatordecorators - Use
class-transformerfor type coercion (@Type(),@Transform()) - Create separate DTOs for Create, Update, and Response operations
- Never trust raw user input — validate everything
See references/api-validation-dto.md for enforcement rules.
6. Database Patterns (Drizzle ORM)
Integrate Drizzle ORM following NestJS provider conventions:
- Wrap the Drizzle client in an injectable provider
- Use the Repository pattern for data access encapsulation
- Define schemas in dedicated schema files per domain module
- Use transactions for multi-step operations
- Keep database logic out of controllers
See references/db-drizzle-patterns.md for enforcement rules.
Best Practices
| Area | Do | Don't |
|---|---|---|
| Modules | One module per domain feature | Dump everything in AppModule |
| DI Scoping | Default to singleton scope | Use REQUEST scope without justification |
| Error Handling | Custom exception filters + domain errors | Bare try/catch with console.log |
| Validation | Global ValidationPipe + DTO decorators | Manual if checks in controllers |
| Database | Repository pattern with injected client | Direct DB queries in controllers |
| Testing | Unit test services, e2e test controllers | Skip tests or test implementation details |
| Configuration | @nestjs/config with typed schemas | Hardcode values or use process.env |
Examples
Example: New Domain Module with Validation
When building a "Product" feature, follow this workflow:
1. Create the module with proper encapsulation:
// product/product.module.ts
@Module({
imports: [DatabaseModule],
controllers: [ProductController],
providers: [ProductService, ProductRepository],
exports: [ProductService], // Only export what others need
})
export class ProductModule {}
2. Create validated DTOs:
// product/dto/create-product.dto.ts
import { IsString, IsNumber, IsPositive, MaxLength } from 'class-validator';
export class CreateProductDto {
@IsString() @MaxLength(255) readonly name: string;
@IsNumber() @IsPositive() readonly price: number;
}
3. Service with error handling:
@Injectable()
export class ProductService {
constructor(private readonly productRepository: ProductRepository) {}
async findById(id: string): Promise<Product> {
const product = await this.productRepository.findById(id);
if (!product) throw new ProductNotFoundException(id);
return product;
}
}
4. Verify module registration:
# Check module is imported in AppModule
grep -r "ProductModule" src/app.module.ts
# Run e2e to confirm exports work
npx jest --testPathPattern="product"
Constraints and Warnings
- Do not mix scopes without justification —
REQUEST-scoped providers cascade to all dependents - Never access database directly from controllers — always go through service and repository layers
- Avoid
forwardRef()— restructure modules to eliminate circular dependencies - Do not skip
ValidationPipe— always validate at the API boundary with DTOs - Never hardcode secrets — use
@nestjs/configwith environment variables - Keep modules focused — one domain feature per module, avoid "god modules"
References
references/architecture.md— Deep-dive into NestJS architectural patternsreferences/— Individual enforcement rules with correct/incorrect examplesassets/templates/— Starter templates for common NestJS components
Related skills
More from giuseppe-trisciuoglio/developer-kit and the wider catalog.

nestjs-code-review
Comprehensive code review for NestJS applications covering controllers, services, modules, guards, and DI patterns.

nestjs-drizzle-crud-generator
Generate complete NestJS CRUD modules with Drizzle ORM, Zod validation, and tests.

nextjs-app-router
Patterns and code examples for Next.js 16+ App Router architecture with Server Components, Server Actions, and caching.

nextjs-authentication
Auth.js 5 authentication patterns for Next.js 15+ App Router with OAuth, protected routes, and RBAC.

nextjs-code-review
Comprehensive code review for Next.js App Router applications with best-practice validation.

nextjs-data-fetching
Next.js App Router data fetching patterns: server/client strategies, SWR, React Query, ISR, and revalidation.