Как стать автором
Обновить

Комментарии 10

наоборот все джойнят на клиенте , тот же ютуб перешел на вариант 1 . А в ынаоборот на 2й переходите...

Не совсем, в связке именно с Bitrix для достижения максимальной производительности приняли решение джойнить запросы на бэке.

Я прям даже теряюсь от чего меня больше трясет - от связки битрикса и nuxt или от некоторых тезисов, типа "html кеш из базы" или "ssr маст хев". Куча лишней работы, имхо, все эти задачи решает битрикс из коробки, не понимаю нужды городить такие огороды

Вы тоже получаете процент с продажи Битрикс коробки?
Если да то понятно, если нет, то в чем сложность выбрать нормальный стек для крупного e-commerce проекта?

Почему люди в 2021 все еще используют битрикс-cms, я наверное никогда не пойму.

битрикс в 2021 году может быть потому что его внедрили в 2011 году, проект вырос и слезть с этого изделия долго, дорого и больно

Похожая история была на 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).

НЛО прилетело и опубликовало эту надпись здесь

Тут требования клиента в плане админки и функционала скидок, корзины и т.д. Ему админкой пользоваться удобно.

Конечно, если бы это было возможно, мы бы взяли более легкий фреймворк, и не обязательно даже на php.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.