Писал на cordova, пишу на capacitor. Полёт нормальный. Разработка куда дешевле, чем иметь два штата разработчиков на обе платформы.

Но тогда усилим сложность. 5 роутов отдавали в одном формате, еще 5 добавились, где надо подмешивать.

ДТО разные для этих роутов

Это понятно что дешевле. Ещё дешевле делать сайты на готовых админках, wp, без отдельного фронта. Но серьёзные проекты как то все больше без этого стараются, так как гибкость ниже, а ещё более серьёзные даже от фреймов стараются отходить. Если бы все было так просто, давно бы всякие котлины и свифты забросили в мобилках.

Почему?)

Это понятно что дешевле. Ещё дешевле делать сайты на готовых админках, wp, без отдельного фронта. Но серьёзные проекты как то все больше без этого стараются, так как гибкость ниже, а ещё более серьёзные даже от фреймов стараются отходить. Если бы все было так просто, давно бы всякие котлины и свифты забросили в мобилках.

Вот кстати, ты ж часто умные советы даешь. Есть сущность. Прогоняется нормалайзером кастомным. Как к этой сущности нацеплять доп. информации? Ну, помимо передачи всей этой допы в контекстах.

Тут главное на вопрос себе правильно ответить, является ли дочерняя сущность неотъемлимой частью родителя.

Вот да. Начинаю наконец-то понимать, когда двунаправленность оправданная. И вот конкретно в ситуации коммент-его лайки вполне себе может быть оправданной.

И еще вопрос. Есть эти самые лайки-дизлайки. Роут получения списка комментов. Мне надо отдавать, какую именно оценку какому комменту поставил конкретно данный юзер. Это вот в нормалайзере наверное не имеет смысла юзать? Или в контексте как раз логично передать текущего юзера?

Ну да. Либо получить текущего из SEcutiry, но попахивает дурно. Лучше явно передавать, в КОНТЕКСТЕ какого юзера мы рассматриваем нормализацию.

Ну да. Либо получить текущего из SEcutiry, но попахивает дурно. Лучше явно передавать, в КОНТЕКСТЕ какого юзера мы рассматриваем нормализацию.

извините, а вы какую проблему тут решаете

И да, передавать раздельно комменты, отдельно карту лайков - типа отметаем. Допустим, фронт ендер упёрся и хочет "матрешки" в ответе.

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

мне че сюда код написать чтоли

Имхо, как только переходит их раздела простого "отдать сущность максимум в 1 глубину" и много строк, лучше переходить на голый sql. Там потому что и гидратор начинает норм жрать и жадную надо подключать везде принудительно. И всякую эту магию делать.

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

Вообще, для представления данных, собирать запросы через связи доктрины и запихивать их в нормалайзер, это крайне не экономично, прb 10+ комментариев, у вас на выборку и сериализацию отсчет времени на секунды пойдет. Такие задачи лучше решать через один sql запрос, с последующей пост обработкой. У нас например есть решение когда мы в sql собираем данные по смежным сущностям в поле в виде JSON, дальше парсим в ДТО (своими методами без сарилизатора) и отдаем на фронт, работает быстро на больших объемах и всего один запрос к БД. UserId|UserTitle|EnotherUserFields....|Comments 234441|UserName.|OtherFieldsData......|[{id: 0, comment: 'Hello', likes: [{user_id: 123344, positive: true, time_stamp:'2022-02-02'}]]

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

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

Динамическое формирование запросов это зло

если простой запрос то хоть dql, хоть билдер без проблем заходит, потом результаты в дто через NEW если что-то сложнее то нативный sql через dbal и маппинг в дто, что тут еще придумывать

Научить драйвер БД сразу мапить данные в нужную ДТО, а не прогонять 10раз одни и теже данные циклами

Это же получается какой-то идеальный фоеймворк. Пхп. Скорость. Нормальная ОРМ. Сервис контейнер