Node.js & NestJS

01The event loop in plain words

Imagine a waiter serving many tables alone. He takes an order, hands it to the kitchen and immediately moves to the next table instead of standing and waiting. When a dish is ready, the kitchen calls him. Node works the same way. Your JavaScript runs on a single main thread. When you read a file, query a database or call an API, Node hands the work to the operating system or a small thread pool (libuv) and keeps running other code. When the result is ready, a callback, or a resolved Promise, is queued and the event loop runs it. This is non-blocking I/O. The catch: if your own code does heavy CPU work, like resizing images or a huge JSON parse, the waiter is stuck in the kitchen and every other request waits.

• Phases: timers, pending callbacks, poll (I/O), check (setImmediate), close callbacks.
• Microtasks (Promise callbacks, queueMicrotask) run between each step, before the next macrotask.
• Rule: never block the loop; move CPU work to worker threads or a queue.

02When Node fits, and versions in late 2026

Node is a great fit for APIs that mostly wait on databases and other services, realtime features with many open connections, BFFs (backend-for-frontend layers), webhooks, CLIs and tooling. It is a weaker fit for CPU-heavy number crunching, where Go, Rust or a dedicated worker service do better. For production, use an LTS release: as of November 2026, Node 24 is in maintenance LTS until April 2028, Node 22 reaches end of life in April 2027, and Node 26 has just entered LTS. Modern Node includes fetch, a built-in test runner (node:test), watch mode and native TypeScript type stripping for simple cases, so you need fewer extra packages than a few years ago.

03Express vs NestJS

Express is minimal: a router and middleware, nothing else. That is perfect for a small service, but in a big codebase every team invents its own structure. NestJS gives you that structure. A module groups one domain (orders, menu, loyalty) with its controllers and providers. Dependency injection means a class declares what it needs in its constructor and Nest builds it, which makes swapping a real service for a fake in tests trivial. Around each request Nest runs a fixed pipeline: middleware, then guards (may this user call this?), then interceptors (logging, timing, response mapping), then pipes (validate and transform input), then your handler, then exception filters that turn errors into clean HTTP responses. NestJS runs on Express by default or on Fastify for more throughput.

1@Controller('orders')
2@UseGuards(JwtAuthGuard, RolesGuard)
3export class OrdersController {
4  constructor(private readonly orders: OrdersService) {}
5 
6  @Post()
7  @Roles('cashier', 'manager')
8  create(@CurrentUser() user: AuthUser, @Body() dto: CreateOrderDto) {
9    return this.orders.create(user.companyId, dto);
10  }
11}
12 
13// main.ts
14app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));

04Prisma as the data layer

Prisma lets you describe tables in a schema file and generates a fully typed client: if a column is nullable, TypeScript knows. Migrations are generated from schema changes with prisma migrate dev and applied in production with prisma migrate deploy. Use select or include to fetch only what you need, $transaction for multi-step writes, and client extensions to add cross-cutting rules, such as forcing every query to include a tenant id. Since Prisma 7, connection settings live in prisma.config.ts and the client is created with a driver adapter (for example @prisma/adapter-pg), so check the upgrade guide before moving an older project. Remember that Prisma is not magic: check the generated SQL for slow queries and add indexes in the schema.

1const orders = await prisma.order.findMany({
2  where: { companyId, status: 'PAID', createdAt: { gte: since } },
3  select: {
4    id: true,
5    total: true,
6    customer: { select: { id: true, name: true } },
7  },
8  orderBy: { createdAt: 'desc' },
9  take: 50,
10});

05Worker threads, child processes and Electron

When you must do CPU work in Node, move it off the main thread. Worker threads (node:worker_threads) run JavaScript in parallel threads with their own event loop and communicate by messages; use a pool library rather than spawning a thread per request. For long or retryable work, a queue with separate worker processes (BullMQ) is usually better, because it survives restarts. Scale a Node API horizontally by running several processes (pm2 cluster mode, containers) behind a load balancer. Electron is Node plus Chromium in one desktop app: the main process has Node access, renderer windows show your React UI, and a preload script exposes a small, safe API between them. Keep contextIsolation on and nodeIntegration off in renderers.

06Production tips

Validate all input at the edge with DTOs (class-validator) or zod. Handle errors with exception filters and never let a rejected Promise go unhandled. Log as structured JSON with a request id. Implement graceful shutdown: on SIGTERM, stop accepting traffic, finish in-flight requests, close database and Redis connections. Add health checks for the load balancer. Set timeouts on every outgoing HTTP call. Keep dependencies few and audited, pin your Node version in .nvmrc or engines, and build to plain JavaScript in Docker images instead of running TypeScript through a dev tool in production.

• app.enableShutdownHooks() in NestJS so onModuleDestroy hooks run.
• Watch event-loop lag as a metric; rising lag means something is blocking.

07Measuring a blocked event loop and the libuv thread pool

You cannot fix blocking you cannot see. Node ships monitorEventLoopDelay in node:perf_hooks: it samples how late the loop runs its timers, and a rising p99 means some synchronous code is hogging the thread. Export it as a metric next to request latency. To find the culprit, record a CPU profile with node --cpu-prof under load and open the .cpuprofile file in Chrome DevTools; the widest bars are your hot functions, often JSON.parse on huge payloads, synchronous crypto or a regex with catastrophic backtracking. A second, quieter bottleneck is libuv's thread pool, which has only 4 threads by default. File system calls, dns.lookup, zlib, pbkdf2 and scrypt, and many native hashing modules share it, so 50 concurrent password hashes queue behind each other. Raising UV_THREADPOOL_SIZE at startup helps, but moving heavy work to a worker pool is the real fix.

1import { monitorEventLoopDelay } from 'node:perf_hooks';
2 
3const loop = monitorEventLoopDelay({ resolution: 20 });
4loop.enable();
5 
6setInterval(() => {
7  const p99ms = loop.percentile(99) / 1e6; // nanoseconds to milliseconds
8  metrics.gauge('event_loop_delay_p99_ms', p99ms);
9  if (p99ms > 200) logger.warn({ p99ms }, 'event loop is blocked');
10  loop.reset();
11}, 10_000).unref();

08Request context with AsyncLocalStorage

In PHP each request is its own process, so 'the current user' is easy. In Node, thousands of requests interleave on one thread, so a global variable would mix them up. AsyncLocalStorage from node:async_hooks solves this: you start a context at the beginning of a request and every function called from it, across awaits, timers and Promise chains, can read the same store. It is ideal for a request id in every log line, the tenant id for a Prisma extension, or a trace id for outgoing calls. In NestJS the nestjs-cls package wraps it neatly. Two rules: keep the store small and immutable-ish, and always start it in middleware, not in a guard, so everything downstream inherits it. Work started outside the request, such as a queue worker, needs its own run() call per job.

1import { AsyncLocalStorage } from 'node:async_hooks';
2import { randomUUID } from 'node:crypto';
3 
4type Ctx = { requestId: string; companyId?: string };
5export const requestContext = new AsyncLocalStorage<Ctx>();
6 
7// main.ts (Express adapter)
8app.use((req, _res, next) => {
9  const requestId = req.headers['x-request-id']?.toString() ?? randomUUID();
10  requestContext.run({ requestId }, next);
11});
12 
13// Anywhere deeper, even after several awaits
14logger.info({ requestId: requestContext.getStore()?.requestId }, 'order created');

09NestJS injection scopes and their hidden cost

By default every NestJS provider is a singleton: created once at startup and shared, which is fast and usually correct. Scope.REQUEST creates a new instance per request so it can inject the request object. The catch is that request scope bubbles up: any controller or provider that depends on a request-scoped provider also becomes request-scoped, so one innocent injection can make a whole dependency tree rebuild on every call, adding latency and garbage collection pressure. Prefer singletons that receive context as method arguments or read it from AsyncLocalStorage. If you truly need per-tenant instances, for example a separate connection per tenant, NestJS offers durable providers with a ContextIdStrategy, which keeps one sub-tree per tenant instead of per request. Dynamic modules with forRootAsync and ConfigService are the clean way to build configurable singletons at startup.

10Memory, streams and database connections

Node's heap is limited, so loading a 500 MB export into an array crashes the process with 'JavaScript heap out of memory'. Streams process data in small chunks, and stream.pipeline connects them with backpressure: if the destination is slow, the source pauses instead of buffering everything. Async generators are readable sources, so you can page through the database and write CSV lines directly. For leaks, start the process with --heapsnapshot-signal=SIGUSR2, take two snapshots minutes apart and compare what grew in DevTools; typical culprits are unbounded in-memory caches, listeners never removed and closures holding large objects. Connections are the other limited resource. Each process should create one Prisma client; with Prisma 7 driver adapters the pool size is set on the driver, such as the pg Pool max. Multiply pool size by process count and keep the total below the database limit, or put PgBouncer in front.

1import { pipeline } from 'node:stream/promises';
2import { createGzip } from 'node:zlib';
3import { createWriteStream } from 'node:fs';
4 
5async function* ordersAsCsv(companyId: string) {
6  yield 'id,total,created_at\n';
7  let cursor: string | undefined;
8  do {
9    const page = await prisma.order.findMany({
10      where: { companyId }, take: 1000, orderBy: { id: 'asc' },
11      ...(cursor && { cursor: { id: cursor }, skip: 1 }),
12    });
13    for (const o of page) yield o.id + ',' + o.total + ',' + o.createdAt.toISOString() + '\n';
14    cursor = page.at(-1)?.id;
15  } while (cursor);
16}
17 
18await pipeline(ordersAsCsv(companyId), createGzip(), createWriteStream('/tmp/orders.csv.gz'));