Комментарии 13
Всегда нужно помнить, какие модули где и как зависят от других модулей, чтобы можно было встроить один сервис из одного модуля в сервис другого модуля
Чтобы использовать сервис из модуля, разве недостаточно просто подключить модуль, в котором этот сервис объявлен?
Если у сервиса нет зависимостей, то так теоретически можно. А так придётся все зависимости в providers добавлять и тогда уж проще будет сделать только один модуль на весь проект
Поэтому проще сделать export сервиса и импортировать модуль, если делим на модули всё
Т.е. тут не как в ангуляре? Там модуль внутри себя содержит все необходимое, и достаточно подключить модуль, он внутри потянет сам все необходимое.
Вот у меня есть модуль А, который зависит от модулей Б и С и который экспортит сервис А. Могу я подключить в своем приложении тупо модуль А и из него юзать сервис А?
Да, можете. Похоже, что автор статьи что-то напутал либо использовал модули некорректно.
Такое может случиться разве что если вы будете расширять например клас одного сервиса от другого. У меня была подобная ситуация, но я сразу понял что делаю что-то не так и исправил этот момент.
Да и в правду напутал, просто неправильно прочитал комментарий. Подумал, что просто импортировать сервис.
Чтобы использовать сервис надо импортировать модуль, который его экспортирует, в модуль сервиса, к которому мы хотим подключить зависимость от сервиса, как я и писал в статье.
Собственно при увеличении проекта модули зависят друг от друга, что довольно трудно контролировать (те же циклические зависимости, благо Nest помогает немного с этим). А если делать модули больше, например, либо по слоям архитектуры, либо просто один большой модуль на проект, то толку от модулей нет.
NestJS прекрасный фреймворк под Node.js, вдохновлённый серьёзными фреймворками Spring, ASP.NET Core, Simfony.Откуда это? Сами разработчики писали, что они вдохновлялись Ангуляром 🤔
разработка превращается в постоянный ад из-за постоянно неправильно настроенных модулей, расстановки их зависимостейНо ведь вы тут сами пишете, что проблема именно в неправильной настройке модулей.
Откуда это? Сами разработчики писали, что они вдохновлялись Ангуляром 🤔
Да, модули они явно взяли из Angular 2 (поэтому в статье так много отсылок к нему), что стала "вишенкой" этого фреймворка. Но остальные концепции явно из других фреймворков, например, контроллеры с декораторами - аналог контроллера с аннотациями (JavaEE/Spring) или с атрибутами (ASP.NET).
Но ведь вы тут сами пишете, что проблема именно в неправильной настройке модулей.
В том-то и проблема, что такая абстракция, как модули, может эффективно использоваться только в конкретных кейсах определённой архитектуры проекта, но в большинстве случаев они только замедляют и усложняют разработку, не привнося явных плюсов. Даже разделение проекта на npm-пакеты, если нужна модульность, проще, гибче и позволяет даже несильно зависеть от самого фреймворка.
По сравнению с другими языками, где интерфейсы это first-class citizens и DI элегантно пользуются этой особенностью, nest.js вынужден подстраиваться под специфику TS/JS, где ни каких интерфейсов в рантайме не существует. Отсюда кастыли с декоратором Inject и токенами. Это добавляет лишний шум в код, но лучшего пока не придумали.
Модули nest.js описывают жизненный цикл объекта в рантайме - когда и как создавать - чего нет в обычных es6 модулях или npm пакетах. Наличие циклических зависимостей говорит о проблеме в декомпозиции.
Не рассматривали в качестве альтернативы adonisjs.com ?
Не совсем понял смысл этой статьи, хотя я и не использую Nest на постоянной основе и с ее внутренними проблемами не знаком. Как по мне Nest так хорошо заходит в сообществе, потому что ему нет альтернатив на данный момент, хотя то, что предлагает этот Фреймворк, а именно обмазывание декораторами, которые могут быть со временем вытеснены стандартными, если те будут приняты, и сомнительными инъекциями зависимостей, меня отталкивает от его использования. По-моему скромному мнению Фреймворк, использующий чистую архитектуру, можно написать и без сомнительных конструкций, не являющихся частью стандарта языка.
Почему я люблю и ненавижу NestJS?