Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells,

глупую архитектуру с кучей наследования

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

По поводу ОРМ, от сырых запросов ты не убежишь ни на одном языке. Менять базы данных как перчатки нельзя. Поэтому ОРМ это лишь синтаксический сахар. Для простых запросов подходит да и ладно. Не везде нужно использовать всю мощь ОРМ.

Ява крутая да, там и транзакции на уровне языка, но и время разработки повыше. И компонентов для веба готовых очевидно меньше чем на php.

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

И резюмируя все таки получается что inertia отлично вписывается в концепцию laravel Готовое опен соурс решения на паттернах ты все равно не найдешь. А если что то не устраивает, можно надстроить под себя, отключить что не нужно.

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Чем накладно? nuxt популярен. Angular из коробки предлагает universal, его подключение - одноразовая акция не требующая особых сил.

Ну это уже называется не самому пилить, а использовать готовое решение.

SSR вообще бессмысленный, по большому счету. Как только парсеры начнут нормально работать с JS - нужда в SSR отпадет.

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

Как и laravel. Это не делает его хорошим для всех целей и всех проектов.

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

И это нормально? Люди ориентируются на такой код и считают, что раз оно так в доке - то это нормально. А это не так. Аргументировать или ты согласен? Просто не совсем ясно из твоего ответа.

Главное чтобы по докам было понятно что можно делать. А как нужно делать это другой вопрос. Пример: документация Zend 1. Там больше паттерном учат чем как пользоваться фреймворком.

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells, User::create(
Request::validate([
'name' => ['required', 'max:50'],
'email' => ['required', 'max:50', 'email'],
])
);

return Redirect::route('users')

Если это в доках, то это норм. Spatie в своих permissions demo app в сидере Permissions написали всю логику. Но это же для примера. Херово если в исходниках такая дичь. А в доках норм. В доках Ларавеля тоже есть такие строчки. Тем не менее это один из лучших доков среди IT

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells, Я inertia не поддерживаю, потому что кроме доков ничего не изучил. Я поддерживаю модульность web приложений.

По поводу говнокода. Мне нравится Vuetify для верстки. Говнокод как внутри так и в прилагаемых компонентах. Папку utils все дела. Но это лучшее на мой взгляд решение чем даже Ant, популярный на реакте. Лучше может только бутстрап 5.

В случае с inertia то же самое. Выбора особо нет, пилить свой SSR накладно и бесмысленно, легче использовать даже говнокод. Как раз по той самой причине, что во всем проекте он не понадобится. А пройдет время и ребята перепишут по нормальному. Главное идея.

Я бы конечно не парился, а просто отдал бы данные через блейд для определенных страниц. А там где надо SPA оставил SPA. Все приложение делать SSR бессмысленно.

inertia это революция для фрилансеров. Можно очень быстро написать небольшое приложение. Либо несколоко страниц превратить в SSR по бырому.

Ко многим через в laravel eloquent - как сделать хитрый запрос?

client_course
id - integer
course_id - integer
doctor_id - integer
client_id. - integer

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

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells, Если основные модули рассмастривать как страницы, и если все нормально с фронтом, то можно использовать как урлы с нескольких модулией так и несколько вариантов бекенда. Ровно как и на бекенде использовать несколько вариантов фронта. В контексте выдаче пользователю Страницы. Будь то SPA или SSR. Зависимость должна быть на абстракциях.

Для заказчика, лучше найти фулстека, который работал на обоих технологиях, и если структура приложения хорошо построена, то он сразу поймет в чем тут дело.
Если же клиент и сервер это 2 приложения, то нужно изучать архитектуру двух приложений вместо одного. Это требует больше времени и гораздо большего знания стеков.

Связь через API - это и есть главный Костыль, чтобы можно было подружить SPA и сервер. Он стал в тренде именно тогда, когда появились SPA. До этого API запросы были просто запросами, но на них не строилась главные зависимости всего приложения. Вынужденое разделение клиента и сервера повлекло множество костылей, связанных с этим.

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

Laragon/Nginx + Laravel + Nuxt: 419 - CSRF token mismatch?

А вообще, переходи сразу на linux. И вместо nuxt подумай о Vue.js

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells, про поддерживание и расширение) Ты ведь представляешь наверное насколько сложно поддерживать систему, которая разделена на фронтенд и бекенд и общается только через апи? Ты говоришь глазами фронтендщика. Бекендщики так же думают про фронтенд. Я как фулстек вижу сдесяток конструкций программы, которые необходимо синхронизировать для успешной работы приложения. И чтобы его было легко обслуживать и масштабировать, оно должно быть разбито на модули. Причем это касается как бэкенда так и фронтенда. В идеале, модули должны быть цельными, как куски бекенда вместе с фронтендом. Типа плагинов. Таким образом можно тестировать модули целиком.

В случае с инерцией, она дает какую то связанность фронта с беком, и вся модульность будет зависеть от бека. Типа graph ql со стороны бэка. Так что в плане расширения и обслуживания приложения это хорошая идея.

Разумеется это идет в угоду производительности. Но если производительность на первом месте, то стоит задуматься о написании какой то публичной части руками на html, css там

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Alex Wells, странно, демо страница у них нихрена не лагает. SSR на то и server side, чтобы передать все управление серверу. Из списка того, что он передает, нужно все, и обычно все это костыляется вручную, а тут из коробки.

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

Избитый вопрос: как быть с роутингом в связке Laravel+Vue+SSR?

Сергей delphinpro, запросы можно вставить в любой хук без проблем. Если проблемы с асинхронностью, используй синтаксический сахар async await. Правильно раскидай методы в computed и methods