Node.js и NestJS

01Event loop простыми словами

Представьте официанта, который в одиночку обслуживает много столиков. Он принимает заказ, передаёт его на кухню и сразу идёт к следующему столику, а не стоит в ожидании. Когда блюдо готово, кухня его зовёт. Node работает так же. Ваш JavaScript выполняется в одном основном потоке. Когда вы читаете файл, делаете запрос в базу или вызываете API, Node передаёт работу операционной системе или небольшому пулу потоков (libuv) и продолжает выполнять другой код. Когда результат готов, колбэк или разрешённый Promise ставится в очередь, и event loop его выполняет. Это и есть неблокирующий I/O. Подвох в том, что если ваш собственный код делает тяжёлую работу на CPU — например, ресайз изображений или парсинг огромного JSON, — официант застревает на кухне, и все остальные запросы ждут.

• Фазы: timers, pending callbacks, poll (I/O), check (setImmediate), close callbacks.
• Микрозадачи (колбэки Promise, queueMicrotask) выполняются между шагами, до следующей макрозадачи.
• Правило: никогда не блокируйте цикл; переносите работу на CPU в worker threads или очередь.

02Когда подходит Node и какие версии актуальны в конце 2026

Node отлично подходит для API, которые в основном ждут базы данных и другие сервисы, для realtime-функций с множеством открытых соединений, BFF (слоёв backend-for-frontend), вебхуков, CLI и инструментов разработки. Хуже он подходит для тяжёлых вычислений на CPU, где лучше справляются Go, Rust или отдельный сервис-воркер. Для продакшена используйте LTS-релиз: на ноябрь 2026 года Node 24 находится в maintenance LTS до апреля 2028, у Node 22 конец жизни в апреле 2027, а Node 26 только что перешёл в LTS. В современном Node есть fetch, встроенный тест-раннер (node:test), watch-режим и нативное удаление TypeScript-типов для простых случаев, так что дополнительных пакетов нужно меньше, чем несколько лет назад.

03Express или NestJS

Express минималистичен: роутер и middleware, больше ничего. Для небольшого сервиса это идеально, но в большой кодовой базе каждая команда изобретает свою структуру. NestJS даёт эту структуру готовой. Модуль объединяет один домен (заказы, меню, лояльность) с его контроллерами и провайдерами. Внедрение зависимостей означает, что класс объявляет в конструкторе, что ему нужно, а Nest сам его собирает, — поэтому подменить реальный сервис фейком в тестах проще простого. Вокруг каждого запроса Nest выполняет фиксированный конвейер: middleware, затем guards (может ли этот пользователь это вызвать?), затем interceptors (логирование, замеры времени, преобразование ответа), затем pipes (валидация и трансформация ввода), затем ваш обработчик и, наконец, exception filters, которые превращают ошибки в аккуратные HTTP-ответы. По умолчанию NestJS работает на Express, а для большей пропускной способности — на Fastify.

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 как слой данных

Prisma позволяет описать таблицы в файле схемы и генерирует полностью типизированный клиент: если колонка nullable, TypeScript об этом знает. Миграции генерируются из изменений схемы командой prisma migrate dev и применяются в продакшене через prisma migrate deploy. Используйте select или include, чтобы получать только нужное, $transaction для многошаговых записей и client extensions для сквозных правил — например, чтобы каждый запрос обязательно содержал id тенанта. Начиная с Prisma 7 настройки подключения живут в prisma.config.ts, а клиент создаётся с драйвер-адаптером (например, @prisma/adapter-pg), поэтому перед переносом старого проекта загляните в гайд по обновлению. И помните: Prisma — не магия. Проверяйте сгенерированный SQL на медленные запросы и добавляйте индексы в схему.

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, дочерние процессы и Electron

Если в Node всё-таки нужно выполнять работу на CPU, уберите её из основного потока. Worker threads (node:worker_threads) выполняют JavaScript в параллельных потоках со своим event loop и общаются через сообщения; используйте библиотеку пула, а не создавайте поток на каждый запрос. Для долгой или повторяемой работы обычно лучше очередь с отдельными процессами-воркерами (BullMQ), потому что она переживает перезапуски. Node API масштабируют горизонтально, запуская несколько процессов (cluster-режим pm2, контейнеры) за балансировщиком нагрузки. Electron — это Node плюс Chromium в одном десктопном приложении: у main-процесса есть доступ к Node, окна-рендереры показывают ваш React UI, а preload-скрипт открывает между ними небольшой безопасный API. В рендерерах держите contextIsolation включённым, а nodeIntegration — выключенным.

06Советы для продакшена

Валидируйте весь ввод на входе через DTO (class-validator) или zod. Обрабатывайте ошибки через exception filters и никогда не оставляйте отклонённый Promise без обработки. Пишите логи в структурированном JSON с request id. Реализуйте graceful shutdown: по SIGTERM перестаньте принимать трафик, завершите текущие запросы, закройте соединения с базой и Redis. Добавьте health checks для балансировщика. Ставьте таймауты на каждый исходящий HTTP-вызов. Держите зависимостей немного и проверяйте их, фиксируйте версию Node в .nvmrc или engines и собирайте в Docker-образах чистый JavaScript, а не запускайте TypeScript через dev-инструмент в продакшене.

• app.enableShutdownHooks() в NestJS, чтобы срабатывали хуки onModuleDestroy.
• Отслеживайте задержку event loop как метрику: если она растёт, что-то блокирует цикл.

07Как измерить заблокированный event loop и пул потоков libuv

Нельзя исправить блокировку, которую не видно. В Node есть monitorEventLoopDelay в node:perf_hooks: он замеряет, насколько поздно цикл выполняет таймеры, и растущий p99 означает, что какой-то синхронный код занимает поток. Экспортируйте его как метрику рядом с задержкой запросов. Чтобы найти виновника, запишите CPU-профиль через node --cpu-prof под нагрузкой и откройте файл .cpuprofile в Chrome DevTools; самые широкие полосы — ваши горячие функции, часто это JSON.parse на огромных payload, синхронная криптография или регулярное выражение с катастрофическим бэктрекингом. Второе, более тихое узкое место — пул потоков libuv, в котором по умолчанию всего 4 потока. Вызовы файловой системы, dns.lookup, zlib, pbkdf2 и scrypt и многие нативные модули хэширования делят его между собой, поэтому 50 одновременных хэширований паролей встают в очередь друг за другом. Увеличение UV_THREADPOOL_SIZE при старте помогает, но настоящее решение — вынести тяжёлую работу в пул воркеров.

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();

08Контекст запроса через AsyncLocalStorage

В PHP каждый запрос — отдельный процесс, поэтому «текущий пользователь» — это просто. В Node тысячи запросов перемежаются в одном потоке, поэтому глобальная переменная их перепутала бы. AsyncLocalStorage из node:async_hooks решает эту задачу: вы открываете контекст в начале запроса, и каждая функция, вызванная из него, через await, таймеры и цепочки Promise, может читать одно и то же хранилище. Это идеально для request id в каждой строке лога, tenant id для расширения Prisma или trace id для исходящих вызовов. В NestJS это аккуратно оборачивает пакет nestjs-cls. Два правила: держите хранилище маленьким и почти неизменяемым и всегда открывайте его в middleware, а не в guard, чтобы всё ниже по цепочке его унаследовало. Работа, запущенная вне запроса, например воркер очереди, требует своего вызова run() на каждую задачу.

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');

09Injection scopes в NestJS и их скрытая цена

По умолчанию каждый провайдер NestJS — singleton: создаётся один раз при старте и используется всеми, что быстро и обычно правильно. Scope.REQUEST создаёт новый экземпляр на каждый запрос, чтобы можно было внедрить объект запроса. Подвох в том, что request scope всплывает вверх: любой контроллер или провайдер, зависящий от request-scoped провайдера, тоже становится request-scoped, поэтому одно невинное внедрение может заставить всё дерево зависимостей пересобираться на каждый вызов, добавляя задержку и нагрузку на сборщик мусора. Предпочитайте singletons, которые получают контекст аргументами методов или читают его из AsyncLocalStorage. Если вам действительно нужны экземпляры на тенант, например отдельное соединение на тенант, NestJS предлагает durable providers с ContextIdStrategy, которые держат одно поддерево на тенант, а не на запрос. Динамические модули с forRootAsync и ConfigService — чистый способ собирать настраиваемые singletons при старте.

10Память, стримы и соединения с базой

Куча Node ограничена, поэтому загрузка экспорта на 500 MB в массив роняет процесс с «JavaScript heap out of memory». Стримы обрабатывают данные маленькими порциями, а stream.pipeline соединяет их с backpressure: если получатель медленный, источник встаёт на паузу, а не буферизует всё. Асинхронные генераторы — это читаемые источники, поэтому можно листать базу страницами и сразу писать строки CSV. Для поиска утечек запустите процесс с --heapsnapshot-signal=SIGUSR2, снимите два снимка с разницей в несколько минут и сравните в DevTools, что выросло; типичные виновники — неограниченные кэши в памяти, никогда не удаляемые слушатели и замыкания, удерживающие большие объекты. Соединения — второй ограниченный ресурс. Каждый процесс должен создавать один клиент Prisma; с driver adapters в Prisma 7 размер пула задаётся на драйвере, например max у pg Pool. Умножьте размер пула на число процессов и держите сумму ниже лимита базы или поставьте перед ней PgBouncer.

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'));