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

Question

[Сергей delphinpro]

Связка обозначена — Laravel + Vue + SSR.

Ключевая проблема — серверный рендер.
Условие — при первичной загрузке страницы НЕ делать запросы данных для страницы.
Для этого отрабатывает ларкин контроллер и вываливает стейт данных в тело страницы, который потом гидратируется в аппликуху на фронте.

Проблема: дублирование роутинга на клиенте и сервере. Если на сервере роуиты не дублировать, то стейт будет пустой и vue будет делать запрос к апи при начальной загрузке + что более важно — для поисковиков серверный рендер будет отдавать пустую страницу, без данных. А этого уж никак допустить нельзя.

Что делать, елки-палки?

Answer 1

[Alex Wells]

Вообще не ясно, причем тут сервер и Laravel, и почему рауты нужно дублировать.

Laravel вообще ничего об SSR знать не должен - этим пусть занимается сервер на ноде. А все, что ему, в свою очередь, нужно сделать - это заполнить VueX (или любой другой стор) нужными данными до рендера страницы. Откуда их брать - решать тебе. Контроль безграничный - загружай какие данные когда хочешь и как хочешь, главное что бы фронт был более-менее нормально написан.

Comments

[Сергей delphinpro]

Я не хочу пилить и поднимать сервер на ноде.
На VPS установлена нода, но она используется только для для выполнения серверного бандла (пакетом spatie/laravel-server-side-rendering).
Для корректной работы нужно собрать стейт на сервере и передать его в функцию рендера.
Чтобы собрать правильный стейт для данной страницы, нужно продублировать роуты в routes/web.php

Я тут подумал, что можно попробовать перекинуть запросы к апи в хуки created(), чтобы они и на сервере дергались, но то ли аксиос под нодой не работает, то ли с асинхронностью какие-то траблы. Не прокатило.

[Камиль Хисматуллин]

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

[Сергей delphinpro]

kami16ru, Знал бы я где проблема =)
Фишка в том, что ssr в принципе работает.
Если laravel подготовит стейт и и дернет entry-server.js с передачей в него контекста (state+url), то он выплюнет готовую html страницу.
Но я хочу избавиться от ларкиных роутов.
Т.е. в контексте передаю только url и пустой стейт. Я так думал, в этом случае бандл должен увидеть отсутствие данных в сторе и дернуть апишку для заполнения, а потом срендерить и отдать html. Так же, как на клиенте. Но что-то идет не так и стор не заполняется. Щас еще логирование вызова апи прикручу, чтобы быть уверенным, выполняются ли запросы, а дальше хз что делать.

[VegasChickiChicki]

Сергей delphinpro, А сторону Nuxt не смотрели? Там уже готовый сервер для ssr есть. Сборка Nuxt + Nuxt SSR + API
на Laravel не подойдет?

[Alex Wells]

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

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

И.е. так, как ты сказал:

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

Скорее всего ты собираешь фронт и axios думает, что он в браузере. Смотри это:
https://github.com/spatie/laravel-server-side-rend...

target: node тебе поможет.

[Сергей delphinpro]

Alex Wells, в общем-то и я о том же. Убрать роутинг, убрать сборку стейта. Всё это уже есть в js бандле.

Про target в принципе я знаю, использовал в другом проекте, без ларки.
А тут даже не подумал проверить. Казалось, что микс сам все разруливает как надо.
Попробую.

Answer 2

[Камиль Хисматуллин]

В недавно вышедшем Laravel 8 есть SSR из коробки, реализованный при помощи inertia.js, которая решает кроме роутинга и другие проблемы, связанные с SSR.

Так же как вариант, вы можете написать artisan команду, которая будет при сборке проекта создавать json файл. На фронтенде пишете маппер json файла и можете синхронизировать руты с методом "name" маршрутизатора Laravel. Примеры в гугле есть.

Comments

[Сергей delphinpro]

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

[Alex Wells]

Глянул.

Нет, не нужно это юзать (intertia.js). Это такая-же хуета, как и Laravel Nova - лагающее гавно, передающее стопятсот тонн инфы на каждый запрос.

Смотри мой ответ.

[Камиль Хисматуллин]

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

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

[Alex Wells]

kami16ru, нет, SSR это фолбек, когда JS не вариант - и.е. временный костыль для поисковиков, пока те не будут нормально это делать сами. Это не значит, что все должно быть на бэкэнде - нет, бэкэнд остается АПИшкой, а не непонятной хуйней, отдающей компоненты, как в случае с intertia.

Если ты про демо intertia - не лагает, да. А попробуй сделать админку на laravel nova и посмотри, сколько тонн мусора там постоянно передается и как оно из-за этого лагает на мобильных устройствах (да и в целом).

И вообще API делается для того, что бы потом можно было использовать его для других целей - мобильной апки, к примеру. Там нет привязки к конкретным компонентам, даже если апка на JS + NativeScript. Тут этот концепт ломается.

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

[Камиль Хисматуллин]

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

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

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

[Alex Wells]

kami16ru, я фуллстэк и сейчас работаю бэкэндом на проекте, разделенном на фронт и бэк, который общается только через API и в котором более 600 эндпоинтов, так что да, представляю.

Но нет, фронт не должен быть никак связан с бэкэндом. Ты же в курсе, что кроме модульного монолита есть еще и микросервисы? Как собрался фронтэнд с ними связывать?

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

А инерция - рушит всю границу и это опять становится одним большим веб приложением без АПИ, и.е. без возможности стороннего использования 3rd party, внутреннего использования или использования для других клиентских приложений, типа мобильных.

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

И intertia - отличный пример таких "laravel грабль". Оно работает только в простых случаях, и то только если написано хорошо, в чем я сомневаюсь.

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

[Камиль Хисматуллин]

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

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

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

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

[Alex Wells]

kami16ru,

Если основные модули рассмастривать как страницы

Нет, модули - не страницы, а части приложения. Это может быть 0 страниц (чисто технический модуль, типа геокода), а может быть 100500.

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

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

Связь через API - это и есть главный Костыль

Ты же понимаешь, что даже используя inertia тебе все равно нужно писать АПИ? create, update, delete - все это реализуется только через АПИ, в каком бы идеальном мире мы не жили. И фронт тоже нужно писать, вместе со всей версткой, стилями, переходами, анимациями, логикой и так далее.

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

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

Еще раз:
1) в сложных ситуациях - эта хуйня не сработает. Не всегда данные достаются с одного урла и с одного бэкэнда.
2) экономит ОЧЕНЬ мало кода
3) мы теряем АПИ для внутреннего использования (ведь бэкэнд не только с фронта дергается), для сторонних разработчиков и других клиентов
4) использование фреймворков, которые intertia не поддерживает (типа angular) - невозможна. А те, которые inertia поддерживает - явно проигрывают angular

Да и уровень разработчиков этого проекта легко определить по этому куску кода:

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

        return Redirect::route('users');

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

[Камиль Хисматуллин]

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

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

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

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

inertia это революция для фрилансеров. Можно очень быстро написать небольшое приложение. Либо несколоко страниц превратить в 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

[Alex Wells]

kami16ru,

накладно

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

Все приложение делать SSR бессмысленно.

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

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

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

В доках Ларавеля тоже есть такие строчки. Тем не менее это один из лучших доков среди IT

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

[Камиль Хисматуллин]

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

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

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

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

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

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

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

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

[Alex Wells]

kami16ru,

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

А это важно? Если есть хорошее готовое решение, то почему нет?

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

Поверь, это не так. Ларка очень любит нетипизированную магию, упрощенные варианты, глупую архитектуру с кучей наследования - всего этого уже достаточно, что бы задуматься. А потом добавляй к этому отсталость пхп, убогие очереди ларки, отсутствие либ для сериализации, отсутствие нормально типизированных ОРМок (доктрина с ее DQL не катит), убогая валидация на стрингах, отсутствие авто-десериализации реквеста в ДТО, частое отсутствие SDK (в отличии от джавы, sdk под которую есть почти у всех, у кого вообще есть sdk), не дружит с roadrunner, убогий и медленный phpunit (даже с paratest'ом) и еще стопятсот проблем.

К тому же, именно PHP говорит мне о том, что он НЕ подходит для проектов, где нужна многопоточность (или, хотя бы, асинхронность) от слова "совсем".

Так что нет, он подходит не для любых целей и проблема вовсе не в архитектуре с коробки)

[Камиль Хисматуллин]

Alex Wells,

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

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

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

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

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

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

[Alex Wells]

kami16ru,

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

Речь об архитектуре фреймворка, а не приложения. Не изменишь ты ее.

Не буду детально расписывать все пункты. Я и так столкнулся с всеми этими проблемами и знаю по себе, меня никто в обратном не переубедит) Отвечу кратко:
нормальная ОРМка должна давать типизацию. Ни eloquent, ни doctrine, ни cycle ее не дает (типизацию таблиц и запросов). Это не ок. Простые или сложные запросы - это не важно.

Проблемы решаемы, но на то, что бы пофиксить их командой в 6-7 человек (наша бэкэнд тима) - уйдут годы, а комьюнити этим заниматся не собирается. Пока что вижу только как развивается Spiral/Cycle из мира ПХП, но там тоже куча нетипизированного говна, как и в ларке, и сама ларка, вместе с ее экосистемой, но и это бесполезно.

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

[tegos]

Alex Wells , kami16ru - молодцы, очень интересный и познавательный диалог у вас

Answer 3

[Сергей delphinpro]

В общем, решение — не заниматься ерундой.
Поднять на VPS express сервер для SPA, а на ларке запилить stateless api.