Комментарии 12
Фронт давно уже живет своей жизнью и бек для него это просто API и ларавел или не ларавел, вроде как все равно.
Но если Laravel – это просто API, нам нужно по-хорошему создавать отдельный эндпоинт. И т.д. и т.п.
Для решения таких болей есть Graphql, когда у вас тьма на беке из кучи всяких микросервисов или тот же старый монолит. Не нужно создавать/обновлять на каждый чих новый ендпоинт.
Фронт давно уже живет своей жизнью и бек для него это просто API
Не совсем. Если делать что-то серьезное для продакшена, когда проектом пользуется широкий круг юзеров (а не интранет-приложение), серверный пререндеринг необходим: начиная от базовых SEO-нужд, заканчивая банальной метрикой FCP.
А еще, порой, страница довольно статична, например блог. В таком случае, пререндеринг еще более эффективен.
Хорошая практика: Сначала контент, а потом уже доезжает javascript.
А зачастую выходит: сначала грузим 2 мегабайта js, потом это дело фризится на пару секунд, а потом только пользователь видит контент.
серверный пререндеринг необходим: начиная от базовых SEO-нужд, заканчивая банальной метрикой FCP.
Ну это не совсем про бекенд и фронт. Статья вроде как про API.
Гугл спокойно парсит и без SSR, а всякие превьюшки тоже можно сформировать.
Ну да, конечно если у вас миллиард юзеров на проекте — экономить нужно на всем.
Если делать что-то серьезное для продакшена
У нас в продакшене сайт без ssr, без адаптивной верстки и с бандалами под пару метров. Но как-то таким "пользователям" как Эпл, Убер итд. на это все равно :) Основная ценность и доступность продукта решает, а не то как сверстаны кнопочки и зарендерины на 100мс быстрей. Хоть я и понимаю желание сделать все по феншую
Большинство статей, которые я пишу, на схожую тему, а именно — какие есть подходы к разработке web-приложений.
Всё, что я пытаюсь донести, — это "да, можно так, но ещё можно и вот так".
Я не говорил о том, нужен ли SSR, я не говорил о том, что давайте все откажемся от использования API. Я говорю, что есть альтернатива и что она не такая уж и плохая и несёт много новых возможностей. Не надо застревать на месте и, упёршись в одну парадигму, зачастую самую хайповую, игнорировать, что мир движется вперёд. Нужно быть открытым новым идеям, даже хорошо забытым старым, переделанным с учётом нового опыта.
И хвастаться тем, что у вас успешно получается говнокодить для гигантских компаний, чей продукт и без ваших сайтов успешно продается, — моветон.
Не надо застревать на месте и, упёршись в одну парадигму,
Кто сказал, что я говнокодю и застрял в одной парадигме? Я вам в пример привел graphql в качестве решения проблем с API. Вы похоже в современные тренды монолит -> микросервис не особо и восприняли как что? Это вы торчите в прошлом с монолитом, php и laravel, пытаясь решить проблему который уже нет с помощью практически ноунейм либы. Венец технологий прямо какой-то.
И хвастаться тем, что у вас успешно получается говнокодить для гигантских компаний, чей продукт и без ваших сайтов успешно продается, — моветон.
Нет не моветон, точно так же как и рассказы о великом на примере сайт визиток или что у вас там на laravel
чей продукт и без ваших сайтов успешно продается
У вас есть данные какой рост в конверсии после внедрения Inertia.js? А на сколько больше трусов продалось, после того как сначала стал приезжать контент, а потом js, разницей в 100мс?
Кто сказал, что я говнокодю и застрял в одной парадигме?
Точно не я.
Это вы сказали, что у вас даже адаптивной верстки нет в 2020, когда половина пользователей на смартфонах.
А про застревать в одной парадигме – это я про смысл своих статей говорил, а не конкретно про вас.
А вот вы пытаетесь меня лично задеть "сайтами-визитками" и т.п.
У вас есть данные какой рост в конверсии после внедрения Inertia.js?
А при чем тут Inertia.js? Я говорил про Uber, Apple и другие компании, которые вы упомянули. Возможно, им не так важно качество сайта, потому что от отсутствия адаптива и двухметровых бандлов меньше айфонов, скорее всего, покупать не станут. Но говорить, что это значит, что все так должны делать, или просто одобрять такой подход не надо.
Single-page Application – это веб-приложение, которое имеет лишь одну HTML страницу. Её контент создается и обновляется с помощью JavaScript.
Когда нам нужна какая-либо информация, вместо того, чтобы отправлять запрос на новую HTML-страницу, мы отправляем запрос на получение JSON-файла с необходимой информацией, которую потом вставляем на ту же самую страницу.
У этого есть свои плюсы и есть свои минусы. Один из минусов – мы не может получить сразу какие-то конкретные данные. Так как страница всего одна, нам приходится сначала загрузить её, а уже оттуда посылать нужный нам запрос.
Благо это решается такими библиотеками, как VueRouter. Они симулируют переходы по страницам в URL-строке. И если нам нужно получить какую-то специфическую информацию, мы просто передаем это в URL.
Важно понимать, что, если мы нажмем на тег <a> и не сделаем preventDefault, мы, как обычно, отправим запрос на HTML-страницу по href. Чтобы этого избежать, в таких библиотеках, как VueRouter, используются специальные ссылки (например, во VueRouter – это <router-link>), которые перехватывают запросы к HTML и вместо этого делают запрос на JSON.
Теперь посмотрим что делает Inertia.js (подробнее тут и тут). То же самое! Она с помощью специальных ссылок перехватывает запросы к HTML и вместо этого отправляет запрос на JSON. А где я пишу настройки для роутинга в router/index.js или в routes/web.php значения не имеет.
Если же вы хотите написать очередной тесно свзанный монолит, не используете определение SPA.
Теперь вы, zogxray, расскажите мне, как я неправильно использую понятие SPA.
Недавно перевёл один проект с VueJS/Laravel API на Inertia/Laravel. Ускоряет разработку за счёт того, что кое где срезает углы. В целом приятная штука, подходит для небольших проектов где заняты 1-2 фуллстэка.
Обнаружил неприятную особенность Inertia - при роутинге, переходе по ссылкам Link, inertia-link, Inertia.visit, reload и ТП. (они же ajax запросы) перерисовывает весь макет страницы, что сводит на нет смысл использовать ее для spa приложений. Ведь из коробки разрушает и рендерит снова весь макет страницы, вместо обновления части в которых изменились данные. Почему-то этот момент опущен во всех каналах и обучениях по inertia. Сначала думал, что недостаточно изучил inertia. Но потом обнаружил в самой ее документации указан этот момент и предлагается использовать в буквальном смысле костыли, которые при сложных вложенных шаблонах не работают. Persistent layouts https://inertiajs.com/pages
В чистом js фреймворке вы просто пишите функцию, которая обновляет конкретный компонент при изменении данных, это и есть суть spa приложения. В inertia ломают этот естественный для фреймворка процесс, а затем предлагают написать костыль, чтобы это работало.
Inertia.js – современный монолит