Middleware и DI: два паттерна, формирующие любой backend

Две ортогональные оси

Прежде чем чинить архитектурную проблему, нужно понять, на какой оси она живёт — иначе тянешься не за тем инструментом. Middleware и внедрение зависимостей отвечают на разные вопросы, и их путаница — частый источник мутной архитектуры:

• Middleware — про ось запроса: что выполняется вокруг обработчика на каждом запросе и в каком порядке. Это динамично, на каждый запрос, упорядочено: auth, логирование, парсинг тела, rate limiting. Прошлый юнит показал, почему этот порядок — граница безопасности.
• Внедрение зависимостей — про ось связывания: какие объекты куску кода дают, вместо того чтобы он конструировал их сам. Это в основном статично, решается на старте и про связанность и тестируемость: обработчик получает UserRepository, а не вызывает new UserRepository() внутри себя.

Одно — конвейер; другое — граф. Запрос путешествует по конвейеру; граф собирается один раз до того, как придёт хоть один запрос.

Зачем нужен middleware: сквозные заботы

Auth, логирование, трейсинг, сжатие и обработка ошибок нужны почти каждому эндпоинту, но не принадлежат ни одному из них. Без middleware каждый обработчик переизобретает их — несогласованно. Middleware выносит эти сквозные заботы в упорядоченные слои, оборачивающие обработчик, чтобы они были написаны один раз и применялись единообразно.

Зачем нужен DI: инверсия управления

Когда класс вызывает new EmailService() внутри себя, он приварен к этой конкретной реализации: нельзя подменить её фейком в тесте, нацелить на другой конфиг или переиспользовать класс в другом месте. Инверсия управления переворачивает это — класс объявляет, что ему нужно (отправитель писем), а что-то внешнее решает, какую конкретную реализацию он получит. Это внешнее место — корень композиции, единственная точка рядом со стартом, которая знает реальные реализации и связывает граф объектов.

Они встречаются во фреймворке

Реальные фреймворки сплавляют оба. Контроллеры NestJS разрешаются из DI-контейнера и сидят за конвейером middleware/guard/interceptor. Express держит DI неявным (вы связываете руками или цепляете к req), но модель middleware явная. Распознавать, на какой оси живёт проблема, — рефлекс сеньора: «этот эндпоинт медленный на каждом запросе» — обычно middleware; «этот класс невозможно протестировать» — обычно DI.

У двух осей очень разные профили стоимости, и именно поэтому их стоит разделять. Стоимость middleware — на каждый запрос и повторяющаяся: каждый слой в цепочке Express обычно добавляет единицы микросекунд накладных расходов, но раздутая цепочка из 12–15 слоёв (auth, логирование, парсинг тела, сжатие, CORS, helmet, rate limit и т. д.) может добавлять порядка 0,3–0,5мс на p50 и 1–3мс на p99, когда в игру вступают GC и медленный асинхронный слой вроде аудит-лога — умноженное на каждый запрос, это уже реальная пропускная способность. Стоимость DI в основном платится один раз на старте: приложение NestJS с несколькими сотнями провайдеров тратит порядка десятков-сотен миллисекунд на сборку графа при загрузке, а затем обслуживает запросы синглтонами с почти нулевой стоимостью связывания на запрос. Так что ошибка в middleware облагает налогом каждый запрос навсегда; ошибка в DI обычно облагает только загрузку (с одним резким исключением — request-scoped провайдеры из урока 04, которые затягивают стоимость связывания обратно в горячий путь каждого запроса).