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. Module boundaries и dependency graph

Связка: Nest q-1..q-3, Nest q-10, Nest q-17.

Что сделать:

1. Нарисуйте module map для сервиса orders: module -> providers -> imports/exports -> owner -> public contract.
2. Отдельно покажите, где живет controller, use-case/service, repository/adapter, DTO и domain error.
3. Найдите один потенциальный circular dependency и предложите boundary fix: facade, domain event, port/interface или shared contract.

Артефакт: Nest module ownership map + dependency-cycle fix note.

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

2. DTO validation и unified error contract

Связка: Nest q-4, Nest q-5..q-6, Nest q-19.

Что сделать:

1. Подготовьте DTO validation для POST /orders или похожего endpoint.
2. Составьте error contract для validation, auth, domain conflict, dependency timeout и unknown error.
3. Покажите mapping: raw exception/domain error -> public error code -> HTTP meaning -> safe message -> requestId -> UI action.

Артефакт: DTO validation sample + error mapping table.

Критерий готовности: вы отделяете transport validation, domain rule и public error response, не отдавая raw exception наружу.

3. Security contour for critical endpoint

Связка: Nest q-7, Node q-9, Node q-14, Senior q-11.

Что сделать:

1. Для endpoint POST /payments/confirm или POST /orders/:id/cancel опишите AuthN, AuthZ, policy owner, rate limit, audit log и idempotency.
2. Заполните security matrix: risk -> guard/policy -> server check -> audit event -> test -> failure response.
3. Добавьте negative paths: no token, expired token, wrong owner, duplicate request, suspicious retry, missing permission.

Артефакт: critical endpoint security matrix.

Критерий готовности: вы показываете, где в Nest внедрять контроль доступа и какие риски закрывает каждый слой.

4. Testing strategy и release gate

Связка: Nest q-12, Nest q-14, Senior q-16..q-17.

Что сделать:

1. Покройте один business flow тремя слоями: unit, integration, e2e.
2. Заполните risk-to-test matrix: risk -> unit -> integration -> e2e -> observability/release gate.
3. Добавьте минимум один negative path, один auth/permission path, один error contract assertion и один rollback signal.

Артефакт: risk-to-test matrix + release gate checklist.

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

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

1. Architecture boundaries: Nest q-1..q-3, Nest q-10, Nest q-17.
2. API and errors: Nest q-4..q-6, Nest q-19.
3. Security and operations: Nest q-7, Nest q-14, Node q-9, Node q-14.
4. Persistence and reliability continuation: Nest q-11..q-13, Nest q-16, Databases q-6, Databases q-15.
5. SQL practice continuation: Клиенты без потери нулевых заказов, Города с выручкой выше порога, Следующая страница заказов.
6. Повторение: через 24 часа пересоберите module map, transaction checklist and risk-to-test matrix без подсказок.

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

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

Partial: вы знаете decorators/providers/guards, но не можете показать ownership map, error mapping или risk-based test plan.

Not ready: вы описываете Nest как "controller-service-module" без contract boundaries, auth policy, observability и negative paths.

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

1. Nest module ownership map.
2. Dependency-cycle fix note.
3. DTO validation sample + error mapping table.
4. Critical endpoint security matrix.
5. Risk-to-test matrix.
6. Release gate checklist для критичного flow.
7. Repository transaction checklist: use-case, DB writes, external calls, outbox/queue, rollback test.
8. Cache/observability map: cache key, invalidation event, DB query span, alert threshold.

Куда дальше

1. Базы данных: углубить transaction, idempotency, migration and cache consistency.
2. SQL-песочница: проверить join/cardinality перед проектированием repository.
3. Мост практики: Backend data-access integration: пройти ORM/query-builder decision, N+1 diagnosis и repository transaction boundary.
4. Tooling и Delivery
5. NestJS