затем что с подобными апи тяжело работать (вы сами с этим столкнулись уже), тяжело кешировать, тяжело инвалидировать кеш, тяжело запросы писать. для решения подобных проблем придумали api gateway. ваше приложение отдает набор рестфул-апишек, а какая-то умная штука умеет сама из джойнить в большой денормализованный ответ для, например, мобильного приложения

Приветствую! Потихоньку изучаю Symfony, совмещая с практикой, и у меня назрел вопрос, на который не могу нагуглить полноценного ответа. Есть такая штука, как security-bundle. Она, мало того, что считается довольно сложной, для понимания новичками, но и навязывает свои правила разработчику. Говорит: вот у меня есть сущность User, у меня есть ролевая модель и прочие штуки. А мне ролевая модель не нужна и сущность пользователя у меня своя. В связи с этим вопрос звучит так: 1. Считается-ли нормальным НЕ использовать security-bundle в symfony, а писать свою авторизацию и ролевую модель? 1.2. Есть-ли возможность в symfony реализовать Guard'ы, наподобие тех, что имеются в NestJS? По сути, мне это и нужно: чтобы перед контроллером выполнялся какой-то код, который потом пропускает или не пропускает запрос дальше.

Приветствую! Потихоньку изучаю Symfony, совмещая с практикой, и у меня назрел вопрос, на который не могу нагуглить полноценного ответа. Есть такая штука, как security-bundle. Она, мало того, что считается довольно сложной, для понимания новичками, но и навязывает свои правила разработчику. Говорит: вот у меня есть сущность User, у меня есть ролевая модель и прочие штуки. А мне ролевая модель не нужна и сущность пользователя у меня своя. В связи с этим вопрос звучит так: 1. Считается-ли нормальным НЕ использовать security-bundle в symfony, а писать свою авторизацию и ролевую модель? 1.2. Есть-ли возможность в symfony реализовать Guard'ы, наподобие тех, что имеются в NestJS? По сути, мне это и нужно: чтобы перед контроллером выполнялся какой-то код, который потом пропускает или не пропускает запрос дальше.

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

Не очень хороший подход в доке описан

а в чем, расскажете?

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

Никто не шарил симфу, на предмет атрибута для исключений из сервис контейнера? нашел в доке тока #[When(env: 'dev')] class SomeClass { //... } но то такое, хочу что-то более конкретное, чтобы исключать всякие ненужные штуки по типу дтошек\сущностей атрибутьом.

есть же эксклюды в ямле

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

У тебя дто в отдельной папке, просто не указывай её в списке папок в services.yml

в контейнере не все классы проекта же, а только граф связанных. если никакой другой сервис не требует класс дтошки как зависимость (а этого нет), то ее выкинут на этапе оптимизации

Пропиши исключения на основании названия файла

А вообще в симфе принято по папкам кидать своим

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

В смысле в рамках юзкейса или фичи тоже раскладывать каждый по папкам? Или в рамках проекта объединять DTO, Transformers и т.д?

В смысле в симфони нет фичей и юзкейсов)

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

И на фичи, и на юзкейсы (всмысле одновременно). Внутри фичи уже можно выделять типы: сервисы, сущности и т.д. Глобально под ДТО выдялять папку не нравится, только локально. Т.е. ДТО привязано к чему то - если к сервису, то должна лежать рядом с ним, если репо то рядом репо. Ну соответсвенно, если ДТО уже несколько то можно сделать папку, но все равно рядом с сервисом, к которым эти ДТО относятся. Профит: не бегать по проекту, работая с какой то частью кода. Можно копировать папку сервиса в другой проект, и в этой папке уже будет все необходимое для него и только для него, а не искать куски по всему проекту. Да и вообще можно называть не ДТО, короче вариков много, но главное - чтобы класть все рядом с тем, с чем используется.

Теперь понял что имелись в виду фичи и юзкейсы одновременно) Так понятно что не делают, это смешение подходов получается. Интересовало именно разделение внутри фичей или свалка в общих папках. Спасибо большое. Удальцова с комом я посмотрел. Это выступления Дмитрия я не видел, с phpconf 2019 года было не очень понятно, точнее понятно, но слишком крупными мазками.) Без опыта осилить мысль сложно.

Ну доклад 2019 был не про эту тему:) Не знаю видели или нет, собственно сам проект аукциона на симфони в стиле by feature https://github.com/ElisDN/demo-project-manager В докладе немного доработок.

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

Он не пилится, он был напилен 2 года назад уже)

Он не пилится, он был напилен 2 года назад уже)

Значит это уже устаревшее легаси )

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

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

Особенно когда к примеру то копируешь проект, удалил лишние папки фичи и всё. Но в Симфе как-то так не принято

Особенно когда к примеру то копируешь проект, удалил лишние папки фичи и всё. Но в Симфе как-то так не принято