общем тот ещё геморрой сделать для nestjs что-то подобное. Попробую объяснить. В GraphQL мы исходим из принципов, что чем больше связность тем лучше. Схема должная получаться нелинейной и получается что-то вроде связей many-many. А в NestJS архитектура линейная, что хорошо ложится на rest, но не на GraphQL. Под линейностью я имею ввиду абстракцию в виде модулей, вот тут на схеме понятно https://docs.nestjs.com/assets/Modules_1.png Получается что у нас огромное количество модулей связано друг с другом и часто не в виде дерева. Начинаются проблемы с разрешением цикличных зависимостей и другие приколы. В конечном счёте в одном из проектов проще было выкинуть нест в пользу graphql-compose и потерять разве что в статической типизации.
В целом вопрос в несте я думаю решаемый, но подстраиваясь под идеологию неста мы сильно теряем в гибкости и получается, что стандартный модуль graphql в несте достаточно неплохо решает свою задачу и не просит кушать.
У меня похожая проблема с жинитьбой была. Моим решением было остановиться впиливать nestjs. И попробовать его впилить позже еще раз, как только первые сервисы поедут на настоящий ddd. А пока свой ioc/di т.к. волосатость схем важнее. Как я сейчас вижу, можно их поженить с нестом, но только всю обертку контроллеров и гардов надо как-то хитро крутить через свои декораторы. Или вообше выбрасывать. И на начальном уровне можно юзать только сервисы, энтити и реджистри. Про линейность контроллеров прям хорошо подметил 👍
А что у тебя за свой DI? Может показать какие-то примеры структуры и какие задачи им решаешь? Интересно прям
Там поделка из двух уровней - персистентный и сервисный. У меня даже язык его не поворачивается назвать полноценным DI. Но для грейсфул шатдауна достаточно. Полноценный DI сейчас пробуем на инвесифай
Обсуждают сегодня