Вопрос не в том как отправлять асинхронные запросы. Вопрос именно по архитектуре приложения.
Front-часть строится на vue.js (nuxt.js), тут только представления, данных никаких нет.
Back-часть в данном случае на PHP, но это не так важно. REST он и есть REST.
В чём проблема:
1) Клиент запрашивает адрес /orders?page=1, к нему летит html+js
2) Когда JS загрузился vue-компонент запрашивает данные через апи, например /api/orders?page=1
И REST API и vue крутятся на одном сервере, в соседних папках лежат, но при этом клиенту приходится посылать 2 запроса на удалённый сервер, это как то костыльно выглядит. С одной стороны схема поможет разместить приложение на разных серверах в дальнейшем, поддерживать мобильные платформы (API не придётся переписывать), но сейчас это только минус, то что запрос идёт через DNS (поиск IP по доменному имени и отправка запроса на этот же сервер).
Вопрос, можно ли реализовать следующую схему:
1) Клиент запрашивает /orders?page=1
2) vue (тут можно и node.js прикрутить, если нужно) обращается к /api/orders?page=1 но не через DNS, а прямо на localhost.
3) Тут же прикручен server side rendering
4) В итоге клиенту приходит уже отрендеренная страничка, но с полноценным SPA функционалом. За счет SSR и однократного HTTP запроса скорость загрузки и отрисовки страницы возрастает в разы (ли)
p.s. в текущем варианте php и рендерит и подготавливает данные. Сам к себе внутри одного HTTP-запроса он прекрасно обращается и работает очень быстро, но я задолбался писать отдельно js/Jquery логику, а учитывая что это всё нужно строить компонентами, то ещё тяжелей
nuxtServerInit
routerMiddleware
Вроде даже и примеры на сайте есть...
Но держать нюкст ради рендера вью - имхо неадекватно.
Лучше страничку с json данными внутри скрипта отдать пользователю, а пользователь уже подгрузит и vue и все остальное.
Например: ставишь через vuecli webpack шаблон, делаешь сайт, делаешь build. Далее dist кидаешь в проект с пхп. Внутри index.html рендерите раздел script и в переменную гоните полученные с бд данные. Это хоть и менее деликатный способ, но куда более приятный в плане экономии ресурсов за счёт избавления от рендера nuxt и лишних запросов с того же nuxt к бд.
Если возникнут вопросы по поводу поисковика - то гугл не умеет индексить только если инфа грузится после загрузки страницы. В нашем случае инфа уже есть в переменной
numfin, Nuxt хотелось бы использовать ради удобной сборки. Одна npm команда и всё готово к работе, меняй маршруты да шаблоны пиши. Поэтому и хотелось его взять.
Уточню по примеру, правильно ли я понял.
1) Пишу проект на vue, когда всё готово рендерю html-ки.
2) Кидаю их в проект с php
3) Под каждый запрос, с помощью php переписываю оригинальный html на
"html ..." + let data = {данные из бд} + "+ html"
4) Отдаю результат клиенту. В таком случае останется подождать пока инициализируется vue.js и который вставит данные из JSON в шаблон.
Так?
GET /orders - запросить все заказы
GET /orders?page=1 - запросить заказы c применением фильтра, например на страницу выводится по 10 заказов. Как же иначе нам сделать выборку ограниченной? Если в базе 10 млн. заказов? Зачем лишнее запрашивать?
Вернуться должен JSON
JSON должен вернуться от API, а если фронт это обычный html или динамические-шаблоны, то в первом варианте, от которого я хочу уйти сначала должен прилететь этот хтмл, а потом уже JS запрашивает данные от API. Собственно от нескольких синхронных HTTP-запросов я и хочу уйти
если проблема в двух отдельных запросах для фронта и для данных то вам нужно смотреть сюда https://ru.vuejs.org/v2/guide/ssr.html
Но имхо трогать SSR пока у тебя сайт не сможет отбить затраты на его внедрение, нет смысла.
Вся суть SPA в том, что первый запрос тебе должен отдать быстрый сервер, который обслуживает только статику, у него нет затрат на рендеринг страницы, частенько это делает nginx, а вот запросы к АПИ уже обслуживает медленный сервер, который поднимает Яву, ПХП, Питон ну или что угодно, для того чтобі сформировать тебе данные.
И да, SSR это как правило уже не PHP а node.js чтобы не дублировать бизнес логику
1. nuxt позволяет отрендерить страницы и создать статику. Можно будет уже её залить на сервер. Но мне кажется, что как-то не правильно делать 2 запроса на разные адреса. Типа сначала host.tld, а потом api.host.tld, да, статика сразу отдаётся, но нужно же ещё время на отправку сигнала, обратный возврат, а если человек в метро едет где связь пропадает? Ему статика прилетит, потом связь пропала, потом ждать десятки секунд пока данные прилетят? Если рендер на сервере и данные сервер же запрашивает, то если к нам что и прилетит, то это уже готовая страница, как минимум текст будет загружен.
2. Nuxt.js из коробки позволяет делать SSR, если у нас сайт на сайте простой роутинг страниц на 10, то настройка ssr и всего проекта займёт несколько минут. Я хочу узнать, можно ли заставить сервер, например ноду запрашивать данные у PHP находящегося на той же машине, чтобы клиенту прилетала уже отрендеренная страница.
Но мне кажется, что как-то не правильно делать 2 запроса на разные адреса. Типа сначала host.tld, а потом api.host.tld
вам действительно кажется
статика сразу отдаётся, но нужно же ещё время на отправку сигнала, обратный возврат, а если человек в метро едет где связь пропадает? Ему статика прилетит, потом связь пропала, потом ждать десятки секунд пока данные прилетят?
это нормальное поведение, для этого различные лоадеры и тексты заглушек встраивают.
суть в том чтобы браузер мог закешировать статику при первом запросе и в дальнейшем только запросы с данными шли.
но если преследует паранойя про метро, тогда стоит подумать, об неожиданном отказе сервера и конечно же о случае, если электричество закончится.
просто для размышления, что лучше:
- человек начал грузить сайт, больше половины загрузил, пропала связь, у него белый экран (причем он не понимает сайт вообще работает или нет), ему надо снова нажать рефреш страницы, как только между станциями появится интернет
- человек сразу видит всю статику сайта с текстами удержания, лоадерами и прочими штуками, пропадает связь, но он хоть понимает что сайт есть и поведение сайта предсказуемо, как только появится интернет, подтянутся остальные данные. (причем вы сможете спокойно кешировать отдельно статику, отдельно запросы к апи и гибко этим манипулировать)
серверный рендеринг зачастую критичен для поисковиков которые не умеют работать с аякс сайтами в плане продвижения. в остальных случаях это допустимые потери, если конечно бек у вас грамотно написан, база с умом спроектирована и верно определены модели данных, которыми вы обмениваетесь.
серверный рендеринг зачастую критичен для поисковиков которые не умеют работать с аякс сайтами в плане продвижения. в остальных случаях это допустимые потери, если конечно бек у вас грамотно написан, база с умом спроектирована и верно определены модели данных, которыми вы обмениваетесь.
Vue нужен скорей не для SPA, а для лёгкой работы с шаблонизацией. Менеджеру нравится открывать по 10 вкладок заказов, чтобы по каждой потом проходиться. Поэтому я и задумался о сокращении кол-ва обращений к серверу и SSR, насколько я понял при SSR полезное содержимое ощутимо раньше показывается на странице. Или я не прав?
если данных много, что при ssr вам тянуть долго будет, что при отдельных запросах в апи, даже если небольшой выйгрыш будет - он не существенный
Менеджеру нравится открывать по 10 вкладок заказов, чтобы по каждой потом проходиться. Поэтому я и задумался о сокращении кол-ва обращений к серверу
вы хотите решить проблемы нагрузки которой нет? это сомнительный подход. Лучше все это время потратте на грамотное кеширование запросов апи и бд, и не создавайте себе лишних проблем)
Хотя не зная всех тонкостей вашей системы, я ничего не утверждаю, лишь предполагаю, и если есть желание запилить ssr - пожалуйста, но в целом лучше делать чтобы все работало хорошо с апи (тогда вы и мобильные приложения сможете к апи подцепить в будущем без проблем или сделать гибридное приложение), а возможность при необходимости сделать ssr я бы просто держал в уме, до лучших времен, когда необходимость действительно оправдается
GTRxShock, вы правы. В долгосрочной перспективе именно так и нужно будет сделать. В среднесрочной хорошее решение предложил numfin, PHP может рендерить vue шаблоны, он же может отдавать страницу сразу с данными, и это не мешает параллельно выделить поддомен или url для API, чтобы другие приложения могли им пользоваться
Простой
