Какой опыт работы с NestJS

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

Понимаете ли вы, как NestJS устроен внутри, или умеете только генерировать модули через CLI. Следом обычно спрашивают про порядок обработки запроса или про циклические зависимости между модулями.

Как отвечать

Коротко о проекте (что за сервис, нагрузка, ваша роль), затем по механике:

• модули и DI: провайдеры регистрируются в модуле, наружу видны только те, что перечислены в exports. По умолчанию провайдер синглтон, есть ещё Scope.REQUEST и Scope.TRANSIENT;
• конвейер запроса: middleware, затем guards, interceptors до обработчика, pipes, сам обработчик, interceptors после, а при ошибке exception filters;
• валидация: ValidationPipe с class-validator и class-transformer, опция whitelist отрезает поля, которых нет в DTO;
• конфигурация: @nestjs/config, forRootAsync для модулей, которым нужны секреты;
• данные: TypeORM, Prisma или MikroORM, где и как вы открывали транзакции;
• транспорт: HTTP-адаптер на Express по умолчанию или Fastify, @nestjs/microservices, очереди на BullMQ;
• тесты: Test.createTestingModule и подмена зависимостей через overrideProvider.

Назовите реальные сложности: циклическая зависимость и forwardRef, долгий старт при сотне модулей, документация через @nestjs/swagger, которая расходится с кодом без аккуратных декораторов. Если NestJS вы знаете по учебному проекту, скажите это и опирайтесь на опыт с Express: Nest построен поверх него, и многие идеи переносятся.

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

Путают guards и middleware. Middleware не знает, какой обработчик будет вызван, а guard получает ExecutionContext и может читать метаданные декораторов, например требуемые роли.

Лечат циклическую зависимость через forwardRef по привычке. Чаще это сигнал, что общую логику пора вынести в отдельный модуль.

Делают сервис request-scoped ради доступа к текущему пользователю. Такой scope пересоздаёт на каждый запрос всю цепочку зависимых провайдеров, а для контекста запроса хватает AsyncLocalStorage или пакета nestjs-cls.