базовая инфа норм, остальное как-то лишнее

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

+ если кешировать, то заебумба

и как тогда в таком кейсе поступить?

Господа подскажите пожалуйста в точки зрения философии.
Есть сущность. например группа.
Есть владелец этой группы тот кто её создал.
Есть ендпоинт "удалить группу"
Соответственно удалить группу может только её владелец.
Внимание вопрос:
Где должна происходить проверка доступности этого ендпоинта?

В Гварде?
В контроллере?
В сервисе?

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

Кто что посоветует?

епаресете

я бы в гварде проверял или в сервисе

в middleware фетчите юзера, в гварде validate, на вход groupId

но так как в сервисе вся инфа будет, то значит в сервисе

а в гварде тебе придётся запрос к базе слать, что как-то не оч

а если в гварде сервис, а внутри сервиса запрос?)

зачем тебе тогда гвард ?

чтобы return bool и без бд

а сервис как подцепить примесью?

вот наследование не нужно )

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

почему кучу то - не пойму. вы тянете role, access и прочие базовые штуки (если есть), если нет - то все в сервисе

какими сущностями владеет пользователь не относится к его конфигурации пермишенов

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

вы все равно не знаете о том может он это делать или нет без запроса самой сущности, на сколько я понял.
не знаю на сколько это по-nestовски, но: если речь об условном ownerId в groups, то вам все равно делать select-предзапрос на проверку (для унификации прав доступа), и nest здесь не сильно важен, поэтому в сервисе групп юзеров у вас должен быть async can(action: string, id: string), возвращающий boolean. вы этот can можете дернуть из гварда, или любого другого места

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