English for NestJS Developers
Learn the key vocabulary and phrases for discussing NestJS modules, decorators, and dependency injection in English at work.
NestJS has become one of the most popular frameworks for building scalable Node.js applications, and its architecture introduces a rich set of concepts that every developer needs to discuss clearly in English. Whether you are joining a standup, writing documentation, or explaining your design in a code review, knowing the right vocabulary will help you communicate with confidence. This guide walks you through the most important NestJS terms and shows you exactly how to use them in real work conversations.
Key Vocabulary
Module A module is the fundamental building block in NestJS that groups related components — controllers, providers, and imports — into a single cohesive unit. Example: “I moved the payment logic into its own module so we can import it wherever we need it.”
Decorator
A decorator is a special TypeScript syntax (prefixed with @) that attaches metadata to a class, method, or parameter, telling NestJS how to handle that element at runtime.
Example: “We use the @Controller decorator to mark this class as a route handler.”
Dependency Injection Dependency injection (DI) is a design pattern where NestJS automatically creates and supplies the dependencies a class needs, rather than the class creating them itself. Example: “Thanks to dependency injection, we don’t have to instantiate the service manually — NestJS handles that for us.”
Provider
A provider is any class decorated with @Injectable() that NestJS can inject into other classes; services, repositories, and factories are all providers.
Example: “The UserService is registered as a provider in the UserModule, so any controller in that module can use it.”
Guard
A guard is a class that decides whether a request should be handled by a route, commonly used for authentication and authorization checks.
Example: “We added an AuthGuard to protect all admin routes — if the token is missing, the request is rejected before it reaches the controller.”
Interceptor
An interceptor is a class that can transform the data coming in or going out of a route handler, often used for logging, caching, or response mapping.
Example: “I wrote an interceptor that wraps every response in a standard { data, status } envelope.”
Pipe
A pipe is a class that validates or transforms input data before it reaches the route handler, helping keep your controllers clean and your data consistent.
Example: “The ValidationPipe rejects the request immediately if the body doesn’t match the DTO schema.”
Controller A controller handles incoming HTTP requests and returns responses; it delegates actual business logic to services (providers) rather than implementing it directly. Example: “The controller should stay thin — just parse the request and call the service.”
Common Phrases
In code reviews:
- “This provider isn’t registered in any module — it won’t be injectable anywhere.”
- “Could we extract this into a separate guard? It’s the same auth check we use in three other routes.”
- “The interceptor is doing too much work — response mapping and logging should probably be split.”
In standups:
- “I’m wiring up the email module today and connecting it to the notification provider.”
- “Blocked on the guard — I need to confirm how we’re passing the JWT secret as a config value.”
- “Finished refactoring the user controller; dependency injection is now working correctly with the updated service.”
In documentation:
- “Register this module in
AppModuleimports before using any of its exported providers.” - “All route handlers in this controller require a valid session token, enforced by
SessionGuard.” - “Pipes run before the method body executes, so invalid data is caught at the boundary.”
Phrases to Avoid
Saying “I injected the module” — you inject a provider (service), not a module. Modules are imported, providers are injected.
Correction: “I imported the AuthModule and injected the AuthService into my controller.”
Saying “the decorator calls the function” — decorators add metadata; NestJS reads that metadata to configure behaviour. They don’t call anything directly.
Correction: “The @Get() decorator marks this method as a GET route handler — NestJS maps incoming requests to it.”
Saying “I disabled the pipe” — pipes are applied per-route or globally; you remove or bypass a pipe, not disable it.
Correction: “I removed the ParseIntPipe from that parameter because the value is already validated upstream.”
Quick Reference
| Term | How to use it |
|---|---|
| module | ”Let’s move this into its own module and export the service.” |
| decorator | ”Add the @Injectable() decorator so NestJS can inject this class.” |
| provider | ”Register the provider in the module’s providers array.” |
| guard | ”Attach the RolesGuard to restrict this endpoint to admins.” |
| interceptor | ”The logging interceptor runs on every outbound response.” |
| pipe | ”Use ParseUUIDPipe to validate the id path parameter.” |