DI-контейнеры в продакшене: графы разрешения, циклы и когда не стоит

Приложение нормально стартует в разработке и падает на продакшен-сервере с Nest can't resolve dependencies of the UserService (?, AuthService). В UserService ничего не менялось. Изменилось то, что AuthService теперь импортирует UserService, а UserService уже импортировал AuthService — цикл. В dev модули случайно загрузились в порядке, который замаскировал это; в prod — нет. Контейнер не глючит. Он говорит вам, что не может уложить круг в линию.

Контейнер — резолвер графа

Снимите декораторы — и DI-контейнер делает одно: читает объявления зависимостей, строит направленный граф и инстанцирует в порядке зависимостей — сперва листья, затем то, что от них зависит, вверх до корня. Это топологическая сортировка. Чтобы создать OrderService(db, payments), он сперва должен создать db и payments; чтобы создать их, разрешает их зависимости, рекурсивно. Для синглтонов он делает это один раз и кеширует экземпляр, так что второй потребитель db получает тот же объект. Контейнер — автоматизированный корень композиции из начала юнита: единственное место, знающее конкретику, теперь механизированное.

Почему циклические зависимости его ломают

Топологическая сортировка существует лишь для направленного ациклического графа. Если A зависит от B, а B от A, нет порядка «листья сперва»: чтобы построить A, нужен B, но чтобы построить B, нужен A. Контейнер обнаруживает цикл и отказывается — это ошибка из Hook. Фреймворки дают лазейку — forwardRef(() => Other) в NestJS — которая ломает дедлок, откладывая разрешение одной стороны до конца конструирования. Но лазейка — запах, а не решение: цикл почти всегда означает два класса, которым стоило бы быть одним, или недостающий третий класс, от которого должны зависеть оба. Тянуться к forwardRef, чтобы заглушить ошибку, сохраняет дефект дизайна.

Жадный против ленивого: когда всплывает отказ

Контейнеры различаются тем, когда инстанцируют. Жадное инстанцирование строит весь граф синглтонов на старте, до обслуживания трафика — NestJS делает так по умолчанию. Ленивое инстанцирование создаёт каждый провайдер при первом использовании. Компромисс — когда кусает плохой конфиг: жадный старт означает, что отсутствующая env-переменная или неразрешимая зависимость роняет буст — громко, немедленно, до того как затронут пользователь. Ленивый означает, что та же мисконфигурация прячется до первого запроса, попавшего в этот путь кода, возможно часами позже, возможно лишь на одном эндпоинте. Для серверных приложений сеньорское предпочтение подавляюще жадное: заплати слегка медленный буст, чтобы превратить ночной рантайм-пейджер в деплой-тайм отказ, который ловит CI.

Скрытые цены

Контейнер не бесплатен. Он добавляет время старта (построение графа), налог на обучение и отладку (стектрейсы идут через код разрешения фреймворка, а ошибки «cannot resolve» — отдельный навык чтения) и соблазн скрытого глобального состояния — контейнер становится местом заначки синглтонов, которые на деле просто глобалы с лишними шагами. Для маленького сервиса, CLI или serverless-функции с крошечным графом ручное связывание в корне композиции — обычные вызовы new в одном файле точки входа — часто яснее и быстрее контейнера. Контейнер окупает цену, когда граф большой, времена жизни смешаны и связывание иначе было бы расползшимся ручным месивом. «Используй DI-контейнер» — решение по масштабу, а не дефолт.