Перейти к основному содержимому

NestJS

Для чего модуль​

Освоить NestJS как платформу для устойчивых backend-сервисов: чистая модульность, управляемые зависимости, предсказуемые контракты и надежная эксплуатация.

Результат после прохождения​

  1. Вы проектируете модули и DI-граф без хаоса и циклических зависимостей.
  2. Вы строите API-слой с понятными контрактами, валидацией и error-handling.
  3. Вы внедряете security и reliability-паттерны на уровне framework.
  4. Вы умеете тестировать Nest-сервисы от unit до e2e.

Термины и аббревиатуры​

ТерминКоротко
DIВнедрение зависимостей
ModuleЕдиница организации фич
ProviderИнжектируемая зависимость
DTOКонтракт данных API
GuardПроверка доступа

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Берите один доменный сервис (например, orders/payments/users) и ведите его через все уроки.
  2. Для каждого решения фиксируйте: риск, компромисс, метрику проверки.
  3. По итогам урока добавляйте артефакт: схема модулей, контракт ошибок, тестовый набор.

Программа модуля​

Урок 1. Модули и DI​

Цель: построить архитектуру Nest-сервиса с прозрачными зависимостями и ownership.

Модульные границы​

  1. Feature modules для доменных зон.
  2. Shared/infrastructure modules с минимальным публичным API.
  3. Явные зависимости между модулями, без «скрытых shortcuts».

DI как инструмент архитектуры​

  1. Провайдеры описывают контракты, а не concrete реализации.
  2. Tokens/interfaces помогают изолировать domain от infra.
  3. Избегайте циклических зависимостей; forwardRef — исключение, а не стратегия.

Где ломается в проде​

  1. Один «God module» для всего приложения.
  2. Сервисы связаны напрямую и трудно тестируются.
  3. Глобальные провайдеры растут без контроля.

Мини-задача (обязательная)​

Нарисуйте модульную схему вашего сервиса: модули, провайдеры, зависимости, ownership. Отдельно отметьте потенциальные циклы и план устранения.

Что спросит интервьюер: как вы предотвращаете деградацию архитектуры Nest при росте проекта.

Критерий готовности по уроку: вы можете объяснить DI-граф и модульные границы так, чтобы новый разработчик быстро вошел в проект.

Урок 2. API слой и контракты​

Цель: сделать внешнее поведение API предсказуемым и устойчивым к изменениям.

Controllers, Pipes, Validation​

  1. Controller только orchestration, бизнес-логика в service/use-case.
  2. DTO и валидация входа обязательны на boundary.
  3. Transform/validation pipeline должен быть единообразным по сервису.

Error handling​

  1. Бизнес- и инфраструктурные ошибки разделены.
  2. Единый error contract (code, message, traceId, context).
  3. Exception filters для консистентного response format.

Где ломается в проде​

  1. Разные endpoint возвращают разные форматы ошибок.
  2. Валидация частично в DTO, частично «где-то внутри сервиса».
  3. Контракт API меняется без deprecation процесса.

Мини-задача (обязательная)​

Соберите API contract для 5 типовых ошибок и добавьте пример валидации DTO + mapping в единый error response.

Что спросит интервьюер: как вы отделяете transport-слой от доменной логики в Nest.

Критерий готовности по уроку: вы можете показать API-слой, где ошибки и валидация стандартизированы на уровне всей системы.

Урок 3. Безопасность и доступ​

Цель: встроить безопасность в архитектуру сервиса, а не добавлять после инцидента.

Guards и authorization​

  1. AuthN/AuthZ проверяются централизованно.
  2. Роли и политики доступа отражены в коде прозрачно.
  3. Критичные операции имеют audit trail.

Interceptors и observability​

  1. Correlation id / trace id проходит через весь запрос.
  2. Логирование структурированное и безопасное (без секретов).
  3. Метрики по latency/error rate на уровне endpoint.

Где ломается в проде​

  1. Бизнес-проверки прав размазаны по сервисам.
  2. Security-логика дублируется и расходится.
  3. Отсутствует наблюдаемость за критичными действиями.

Мини-задача (обязательная)​

Опишите схему защиты для критичного endpoint: аутентификация, авторизация, audit logging, rate limit, error mapping.

Что спросит интервьюер: где в Nest лучше внедрять контроль доступа и почему.

Критерий готовности по уроку: вы можете показать security-контур сервиса и объяснить, какие риски он закрывает.

Урок 4. Надежность и тестирование​

Цель: обеспечить предсказуемое качество сервиса при изменениях и релизах.

Уровни тестов​

  1. Unit для бизнес-логики и use-cases.
  2. Integration для модульных взаимодействий и инфраструктурных границ.
  3. E2E для критичных сквозных сценариев.

Testability by design​

  1. DI облегчает изоляцию зависимостей.
  2. Контракты сервисов упрощают мокирование/подмену.
  3. Тесты покрывают поведение, а не framework internals.

Где ломается в проде​

  1. Тестируют только happy-path.
  2. E2E-слой нестабилен и игнорируется.
  3. Нет release-gate по критичным сценариям.

Мини-задача (обязательная)​

Покройте один бизнес-flow тремя слоями тестов: unit, integration, e2e. Добавьте негативный сценарий и проверку error contract.

Что спросит интервьюер: как вы строите тестовую стратегию для Nest-сервиса под реальные риски.

Критерий готовности по уроку: вы можете доказать надежность сервиса через тестовую систему и эксплуатационные сигналы.

Практика​

  1. Нарисуйте модульную карту Nest-сервиса с ownership.
  2. Подготовьте API contract + error schema.
  3. Опишите security-модель для критичных endpoint.
  4. Реализуйте тестовый набор (unit/integration/e2e) для ключевого flow.
  5. Закрепите связкой: Node.js вопросы -> NestJS вопросы -> Базы данных вопросы.
  6. Проверьте API flow с валидацией и guard-политикой в Песочнице, затем зафиксируйте edge-cases.

Связь с треками и вопросами​

  1. Треки: Middle трек, Senior трек.
  2. Вопросы: NestJS, Node.js.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности​

Вы объясняете Nest-архитектуру через границы, контракты, безопасность и надежность, а не через набор декораторов.

Артефакты после модуля​

  1. Схема модулей Nest с ownership.
  2. API contract + error schema.
  3. Security checklist по критичным endpoint.
  4. Набор тестов и release-checklist для критичного flow.

Куда дальше​

  1. Базы данных
  2. Tooling и Delivery
  3. NestJS