Питання на співбесіді Node.js-розробника

Node.js використовує неблокуючий I/O та event loop: поки чекаємо відповідь від бази чи іншого сервісу, потік обробляє інші запити. Тому один процес обслуговує тисячі одночасних з'єднань.

Для важких обчислень на CPU Node.js підходить гірше — вони блокують event loop. Такі задачі виносять у worker threads або окремі сервіси.

Колбеки передаються функції й викликаються після завершення операції — при вкладеності виникає «callback hell». Проміси й async/await дають змогу писати асинхронний код послідовно і обробляти помилки через try/catch.

Важливо пам'ятати: await у циклі виконує операції по черзі. Якщо вони незалежні, швидше запустити їх паралельно через Promise.all.

Middleware — функція (req, res, next), яка обробляє запит до основного обробника: логування, розбір JSON, перевірка токена, CORS. Вона або завершує відповідь, або передає керування далі через next().

Порядок підключення важливий: наприклад, middleware автентифікації має стояти перед захищеними маршрутами, а обробник помилок (err, req, res, next) — наприкінці.

Код потрапляє в Git, на ноутбуки розробників і в CI — секрет швидко витече. Секрети передають через змінні оточення (process.env), а в продакшні — через менеджери секретів (AWS Secrets Manager, Vault, секрети Kubernetes).

Файл .env додають у .gitignore, а в репозиторії лишають .env.example без реальних значень. Сучасний Node.js уміє читати .env без бібліотек: node --env-file=.env.

Основні фази libuv: timers (setTimeout), pending callbacks, poll (очікування I/O), check (setImmediate), close callbacks. Між фазами виконуються черги process.nextTick і мікрозадач промісів.

process.nextTick спрацьовує одразу після поточної операції, ще до промісів, а setImmediate — у фазі check наступної ітерації. Зловживання nextTick може «заморити» event loop, бо I/O не отримає черги.

Через стріми: дані читаються частинами, і пам'ять не залежить від розміру файлу.

import { pipeline } from 'node:stream/promises';
import { createReadStream, createWriteStream } from 'node:fs';
import { createGzip } from 'node:zlib';

await pipeline(createReadStream('big.csv'), createGzip(), createWriteStream('big.csv.gz'));

pipeline коректно обробляє помилки й backpressure — коли споживач повільніший за джерело, читання призупиняється.

Транзакція потрібна, коли кілька змін мають застосуватися разом: списання й зарахування коштів, створення замовлення з позиціями. У Prisma — prisma.$transaction, у TypeORM чи Knex — окремий об'єкт транзакції, який передають у всі запити.

Типові помилки: виконати частину запитів поза транзакцією через інше з'єднання, тримати транзакцію відкритою під час зовнішнього HTTP-виклику, не обробити відкат при винятку.

Короткоживучий access-токен (5–15 хвилин) і refresh-токен із можливістю відкликання, який зберігають у httpOnly secure cookie, а не в localStorage. Перевіряють підпис, термін дії й алгоритм — не можна приймати alg: none.

У токен не кладуть чутливі дані — він лише закодований, а не зашифрований. Для виходу з усіх пристроїв зберігають список активних refresh-токенів у БД або Redis.

Застосунок має бути без стану: сесії й кеш — у Redis, файли — в об'єктному сховищі. Тоді можна запускати багато екземплярів за балансувальником (Kubernetes, кластер PM2).

Далі — профілювання (clinic.js, --cpu-prof), щоб знайти блокування event loop, кешування, черги (BullMQ) для повільних задач, пули з'єднань до БД з урахуванням кількості екземплярів. Метрики затримки event loop і p95/p99 часу відповіді допомагають вчасно помітити проблеми.

Останні роки було багато випадків зламаних популярних пакетів. Заходи:

• lock-файл і npm ci у CI;
• автоматичні оновлення з перевіркою (Dependabot, Renovate) і npm audit;
• мінімум залежностей, перевірка нових пакетів перед додаванням;
• вимкнення install-скриптів там, де можливо;
• приватний реєстр або проксі з перевіркою пакетів для великих компаній.

Також — принцип найменших прав для токенів публікації і двофакторна автентифікація в npm.

Задачі мають бути ідемпотентними, з обмеженою кількістю повторів і експоненційною затримкою. Окремі черги для різних пріоритетів, dead-letter queue для задач, що постійно падають, таймаути.

Для важливих подій — патерн outbox: подія записується в БД в тій самій транзакції, що й дані, а окремий процес публікує її в чергу. Обов'язково — моніторинг довжини черги та часу обробки, плюс graceful shutdown, щоб воркер не обривав задачі при деплої.

Модулі за бізнес-доменами, а не за технічними шарами: orders, payments, users. Усередині — контролери, сервіси, репозиторії, DTO з валідацією (class-validator або Zod).

Між модулями — чіткі публічні інтерфейси або події, без прямого доступу до чужих репозиторіїв. Конфігурація через ConfigModule з валідацією, глобальні фільтри помилок і інтерцептори для логування. Тести: юніт-тести сервісів і e2e-тести з тестовою БД у Docker (Testcontainers).