nodejs-backend

Graceful shutdown follows one path: stop accepting requests, drain in-flight work, close resources in reverse order of creation, then exit with a bounded timeout. In Fastify, awaiting app.close() handles the HTTP drain; calling process.exit() in a signal handler truncates in-flight responses.

Declare input and response schemas in the route options so Fastify compiles validation through Ajv and serialization through fast-json-stringify. For Zod projects, register fastify-type-provider-zod as the validator and serializer compiler instead of parsing inside handlers.

Default-scoped NestJS providers are singletons, so a mutable field like currentUserId is shared by every concurrent request and overwritten mid-flight. Store request-scoped values in an AsyncLocalStorage context entered once per request rather than on the service instance.

Choose Fastify for JSON APIs wanting built-in validation and serialization, NestJS for large multi-team codebases needing enforced module boundaries, and Hono for small or edge-deployed services. Do the Express 4 to 5 step first, then move configuration, logging, and shutdown before porting routes.

A process that will not exit has open handles: unclosed connection pools, active timers, or listeners added per request. Ensure every resource created at startup has a matching close, and in NestJS call app.enableShutdownHooks() so onModuleDestroy runs on SIGTERM.

Running .ts files directly requires Node 22.6+ with type stripping, and the files must avoid enums, namespaces, and parameter properties. Fastify code works because it needs no decorators, but decorator-based frameworks require a build step.