Какой опыт работы с Node.js и Express

Что проверяют

Для фронтендера это вопрос о границах: писали ли вы серверную часть сами или только ходили в чужой API. Хотят понять, справитесь ли вы с BFF-слоем, моками и SSR-сервером. Следом обычно спрашивают, как в Express обрабатываются ошибки асинхронных обработчиков.

Как отвечать

Опишите, где Node.js был в вашей работе: сборка и dev-сервер (Vite, webpack), SSR на Next.js или Nuxt, BFF, который собирает данные нескольких бэкендов для одного экрана, мок-сервер для разработки. Затем по Express:

• middleware: цепочка функций (req, res, next), порядок подключения важен. express.json() до маршрутов, CORS через пакет cors, логирование запросов;
• маршруты: express.Router() для группировки, параметры пути в req.params, строка запроса в req.query;
• ошибки: обработчик с четырьмя аргументами (err, req, res, next) в конце цепочки. В Express 5 отклонённый промис из async-обработчика сам попадает в него, в Express 4 нужен try/catch или обёртка;
• безопасность: helmet, валидация тела через zod, cookie с httpOnly и sameSite для сессии;
• конфигурация: переменные окружения, в свежих Node.js флаг --env-file заменяет пакет dotenv.

Про Node.js в целом: однопоточный event loop, почему тяжёлая синхронная операция тормозит всех клиентов, что можно вынести в worker_threads.

Приведите свой пример: что за сервис, сколько маршрутов, что было сложным. Если серверной разработки было мало, скажите честно: «писал BFF и моки, продакшен-бэкенд не вёл». Это сильнее, чем изображать бэкенд-разработчика.

Где спотыкаются

Не знают, что в Express 4 ошибка в async-обработчике без try/catch не доходит до обработчика ошибок: запрос повисает, а необработанный отказ промиса в современных Node.js по умолчанию роняет процесс.

Подключают express.json() после маршрутов и удивляются пустому req.body.

Называют кластеризацию лекарством от медленного API. cluster или PM2 дают по процессу на ядро, но не ускоряют запрос, который упирается в базу, сначала нужно найти узкое место.