Короче опять я со своим вопросом по архитектуре. сделал вот

такую штуку, "ручной DI.", в индекс файлах происходит "сборка" модуля и подставление зависимостей. но теперь столкнулся с проблемой например с реализацией authGuard - мидл вары которая будет проверяять авторизован ли юзер или нет. Я ее хочу использовать в роутах, но в то же время эта мидлвара должна импортнуть / как то получить usersRepostiory чтобы после разбора сессии - проверить юзера в базе и добавить его в контекст запроса если он был найден. Для этого он бы должен был импортнуть users/index.js чтобы получить "собраный" модуль но вот незадача - этот индекс же импортит роуты, в которых используется сам этот authGuard. короче circular dependency получается. как быть? что куда вынести? сам authGuard тоже "инжектить" как то? заранее спасибо, сорян за многабукаф.

при каждом запросе лезть в базу вроде как не круто, хоть и иногда неизбежно, тут посмотри в сторону JWT. а циркуляция зависимостей решается выносом из цепочки в отдельную зависимость "двусторонней части", т.е. в твоём случае мидлвара, роуты и пользователи должны быть отдельные модули. (P.S. соответственно и точка входа в приложение - так же отделена всего ) ...ну и встречный вопрос, реально думаешь сделать лучше чем в nest.js ?

Ну вот да, поддержку предыдущего ответчика Ну а если хочешь, то и нест юзает какой-то плагин для di, забыл как называется

это не реальный проект, я конечно же мог подключить какой то typedi, tsyringe, inversify, или даже сам нест, но я хочу попробовать реализовать это без доп. зависимостей в базу лезть ок, давайте не будем начинать очередной спор про jwt :D

у неста самописный, и там ts, т.е. используется рефлексия и "магия типов"

я замечу что если не использовать DI, а обычные импорты, то такого не возникает, ведь routes/guard - верхний уровень, импортируют нижний services/repository т.е. стрелка только в одно сторону

Кто сказал JWT? 👀

ох началось))

почему роуты отдельно?

Короче, сейчас в голову пришло создаешь класс с массивом и методом init class DI { private controllers = new Map(); add(controller) { this.controllers.set(controller, new controller()) } get(controller){ return this.controllers.get(controller); } }

типа service locator?

А откуда зависимость юзеров от роутов?

можно плиз номер скрина чтобы я понял

роуты юзеров зависят от самого модуля

Я только текст читал.

возможно понимаю, тож эксперементирую, только с ECMA в целом, и думаю можно сделать лучше чем в nest, сегодня только возникла идея попробовать сделать nest.js на ELM, ну или как миниум на babel/ts с всякими фичами вроде import * as controllers from './controllers' т.е. автоиморт из дерикторий и генерация свагера сразу, не описывая тонны декораторв... в общем без декоратора в spring-like подходе ну никак же, не представляю как без них можно сделать удобный AuthGuard. Х.З. как писать на чистом node.js, для меня это тож самое что писать на чистом js для браузера.

так сами юзеры от роутов не зависят

посмотрите видос выше, там вполне нормальный апи с бизнес логикой на чистом джс сделан, ну только бабеля немного для импортов

И можно же через ес6 импорт. Вроде проблема цикл зависимостей решается.

можно пример, а то чет не врубаюсь

Почитай про ес6 модули, там по другому импорты строятся. С телефона в кровати лежу, какие тебе примеры)

))

посмотрел на репо, чувство прекрасного от реализации требует чего-то попроще, в бизнес-логике много низкоурвневого кода, я считаю в nest.js его так же много, но и тут его в разы больше. Наверное это вкусовщина, однако уже сильно привык к лаконичности описаний.

А зачем req, res, next пробрасываешь в роутах?

типа обертка (req,res,next) => ... ?

проблема двусторонних зависимостей решаются чисто логически выносом глобальной зависимости в третье из двух, так чтоб двое ссылались на третье а третье ни на кого.

это общая рекомендация которая к сожалению не всегда работает

Ты пишешь router.get(req, res, next) = controller.method(req, res, next) А можно просто router.get(controller.method)

нельзя)) там тогда this теряется и получается this.usersRepository is undefined в контроллере

у вас контролер вызывает репозиторий

Если там простой круд без бизнес логики, то, как по мне, городить интеракторы/сервисы смысла нет

если это раз. два он простой сейчас

я пропустил слой сервисов, как верно подметил товарищ выше, но это не суть, потом могу на сервисы заменить

потом может не наступить

?)

не будет времени исправлять