Comments 10
наоборот все джойнят на клиенте , тот же ютуб перешел на вариант 1 . А в ынаоборот на 2й переходите...
Я прям даже теряюсь от чего меня больше трясет - от связки битрикса и nuxt или от некоторых тезисов, типа "html кеш из базы" или "ssr маст хев". Куча лишней работы, имхо, все эти задачи решает битрикс из коробки, не понимаю нужды городить такие огороды
Похожая история была на Drupal. Был сайт с Drupal и решено ему мобильную версию на React написать.
Правда был нюанс: некоторые модули пишут свой JS в футер и хидер и не было желания все такие модули переписывать, т.е. реактовый интерфейс надо было запускать вместе со всеми друпаловскими JS/CSS и первая загрузка приложения вышла заметно медленнее, чем без React.: https://elibsystem.ru/node/491
Связано также с тем, что реактивное приложение в начале грузит зависимые компоненты и лишь потом отрисовывает, в то время как при стандартном подходе браузер начинает отображать интерфейс сразу по ходу загрузки.
Сверху стандартное отображение, снизу с React.
"В не зависимости должен поменяться футер, хедер или контент после пользовательского действия или нет — из базы данных прилетает HTML и меняет весь интерфейс. "
Вы подразумеваете что это кеш, и он в БД хранится? Какой еще HTML страниц в битриксе может "прилетать из БД"?
Битрикс нормально работает с кешированием, если уметь настроить. На второй запрос вам уже готовый HTML сформированной страницы возвращается. Из файла или памяти, или из БД, где вы настроите хранение кеша. Не надо никаких плясок с json, чтобы его получить. Максимально быстро, если не считать шагов, которые приводят к решению отдать кеш, а не запускать расчеты.
А на первый запрос, при отстутствии такого кеша, хоть каким методом передачи будет одинаковое время на ответ затрачено, потому что надо те-же самые расчеты выпонить.
Возникает ощущение что вам просто с битриксом разбираться не хотелось.
Вы подразумеваете что это кеш, и он в БД хранится? Какой еще HTML страниц в битриксе может "прилетать из БД"?
Тут наша ошибка в статье, спасибо, исправили. Тут речь не о БД, а о backend’е, что с него прилетает весь html и стили. В БД запросы делаются, если это требуется (например, кэш устарел или не был еще создан). Все расчеты/выборки так же кэшируются при необходимости на стороне Битрикс (т.е. backend’а). Но хранится не html кэш, а кэш самих данных. И возвращаются именно они.
А на первый запрос, при отстутствии такого кеша, хоть каким методом передачи будет одинаковое время на ответ затрачено, потому что надо те-же самые расчеты выпонить.
В случае первого запроса (когда пользователь первый раз открыл сайт), время ответа будет “одинаковое”, т.к. будет возвращен html целиком, как и в случае использования просто Bitrix. Будем ли мы использовать чистый Bitrix или связку Nuxt+Bitrix, это не важно, т.к. логика функционала будет одна и та же, и кэш мы будем использовать так же.
Если говорить о втором и последующих запросах, то тут увеличение скорости заключается в том, что с backend’а на каждый запрос прилетает не “5мб” информации (в виде html), а “50 кб” (в виде json).
Nuxt: скорость и seo для интернет-магазина