NestJS · TypeScript · Node.js

How NestJS Boots: Factory Pattern, Module Assembly, and Dependency Injection from Scratch

By 嘟嘟0717 · Aug 17, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

NestJS is the dominant enterprise Node.js framework for pure backend work—APIs, microservices, and system integration—and its startup sequence reveals the architectural assumptions every production service inherits. Understanding the factory entry point, module assembly, and DI wiring upfront prevents the common confusion where developers treat the scaffold as magic and struggle to debug injection failures or module misconfiguration later.

Summary

A NestJS application begins in `main.ts` where `NestFactory.create(AppModule)` acts as a factory, constructing the server without manual instantiation. The root module `AppModule` declares its controllers and services inside a `@Module` decorator, and the framework assembles them at startup. Controllers handle routing and simple logic, while services contain business logic and data access; the two layers connect through constructor-based dependency injection, triggered by `@Injectable()` and the `providers` array.

A Mixue Bingcheng demo illustrates the factory pattern: callers request a product by type from `MixueFactory.create()` and receive an object that implements a common interface, never touching the concrete classes. The same pattern underpins `NestFactory.create()`, which accepts a module class and returns a fully wired application instance.

A traced request to `localhost:3000/` shows the full chain: the HTTP listener forwards to the root module, which routes to `AppController.getHello()`, which delegates to `AppService.getHello()`, and the returned string becomes the response body. The scaffold omits a real database, view layer, and parameter validation, leaving those as the natural next steps beyond the hello-world stage.

Takeaways

— `NestFactory.create(AppModule)` is a factory method that builds the entire application instance; you never manually instantiate the server or its internal wiring.

— `AppModule` uses the `@Module` decorator with `controllers` and `providers` arrays to declare which classes the framework should assemble at startup.

— Controllers receive HTTP requests and handle routing and simple validation; services own business logic and data access, and controllers call services rather than doing the work themselves.

— Dependency injection requires three cooperating pieces: the class must be listed in `providers`, decorated with `@Injectable()`, and requested via a constructor parameter in the consuming class.

— The factory pattern decouples callers from concrete classes—`MixueFactory.create(type)` returns a product by a shared interface, and `NestFactory.create(AppModule)` applies the same idea to application construction.

— A GET request to the root path flows from the HTTP listener to the root module, to the matching controller method, to the service method, and back as the response body.

— The hello scaffold implements only Controller and Service layers; a real Model with a database, parameter validation via Pipes, and the View layer are absent and must be added for any practical service.

Conclusions

The `switch` statement in the factory demo lacks a `default` case, so an unrecognized type returns `undefined` and crashes at runtime—a small omission that mirrors real production bugs when factories don't guard against unknown inputs.

NestJS's dependency injection looks automatic but is brittle: omitting any one of the three required pieces—`providers` entry, `@Injectable()`, or constructor parameter—silently produces `undefined` rather than a clear error, which trips up newcomers who assume the framework will warn them.

The scaffold's MVC claim is aspirational rather than implemented; calling a two-class setup 'MVC' when the Model and View are entirely missing sets an expectation that the framework alone provides structure, when in practice the developer must supply the database layer and response formatting.

Concepts & terms

Factory Pattern

A creational design pattern where a factory method creates objects without exposing the instantiation logic to the caller. The caller requests an object by a type or parameter, and the factory returns an instance that conforms to a known interface. In NestJS, `NestFactory.create(AppModule)` acts as the factory, producing a fully configured application server from a module class.

Dependency Injection (DI)

A technique where a class receives its dependencies from an external framework rather than creating them internally. In NestJS, when a class is marked `@Injectable()` and listed in a module's `providers` array, the framework automatically instantiates it and passes it into any constructor that requests it as a parameter.

Decorator Pattern (in NestJS)

NestJS uses TypeScript decorators (prefixed with `@`) to attach metadata to classes and methods at design time. The framework reads this metadata at startup to determine roles: `@Module` identifies a module, `@Controller` marks a request handler, `@Get` binds a method to a GET route, and `@Injectable` flags a class for dependency injection.

Module (NestJS)

A class annotated with `@Module()` that serves as a logical boundary and assembly point. It declares which controllers handle incoming requests (`controllers` array) and which services provide business logic (`providers` array). The root module is the application's entry point for wiring everything together.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗