Комментарии 187
Для примера далеко ходить не надо. Посмотрите на Smashing Magazine. Они активно создают контент и у них JAMstack.
У них лежит около 4к md файлов и из них генерируются страницы.
А где можно почитать про их движок и пайплайн?
Об этом не подскажу. Конкретно про JAMStack, MD-файлы и генерацию Виталий Фридман рассказывал в этом мастер-классе на HolyJS Online https://www.youtube.com/watch?v=x7S1YrP8GOg
А сайты, динамическая версия которых может быть просто запечена в статическую, к приложениям не имеют никакого отношения, имхо.
Вот именно. Статья как навязчивая реклама. Для приложений, где на странице много что меняется, совершенно не подходящее решение. Как пример — много где рекламные блоки меняют содержимое неоднократно, их что, каждый раз перегонять туда сюда…
Сейчас у меня открыто в браузере: gmail, habr, linux org, jira, fisheye, youtube, confluence и reverso context. Для какого из этих рерурсов актуальна рекламируемая новаторская технология?
А чем это отличается от сайта основанного на angular или react? Ну это же, блин, дословно, то же самое.
У нас магазин, пусть будет 1000 товаров.
Значит мы генерируем 1000 отдельных статических страниц, по одной для каждого товара, с той информацией, которая практически не меняется или меняется редко — фото, описание, сопутствующие товары. После загрузки такой страницы через JS подтягивается оперативная информация — остатки по складу, цены, скидки и т.д.
То есть получаем смещение в сторону кэшированного SSR, по сравнению с полным CSR в Angular/React/Vue.
На примере с магазином всё отлично будет работать… Сервер должен возвращать страницу без цены и наличия, а браузер уже дёргает эту инфу асинхронно…
При изменении товара не нужно перезапускать ребилд проекта, просто при сохранении удаляем файл с кэшем и всё, можно даже удалить файл и в фоне запустить сразу создание файла
У меня такое ощущение, что это просто новый вид кэша =)
>Разница в том, что в случае с SPA флоу выглядит так:
Да почему это вдруг? Никто же не запрещает встроить скрипты прям в страницу, и у вас не будет этапа загрузки js. Почему пользователь видит «белую страницу»? Разве SPA приложения определяют такое поведение? Да ничего же подобного, отдавайте страницу с внятным содержимым, изменяйте её по мере поступления данных.
>Здесь идея в том, что мы сразу отдаем Index.html с контентом
А как эта идея противоречит SPA дизайну приложения? Если есть возможность отдать страницу сразу с контентом, то я её отдам сразу с контентом, контент будет встроен в HTML. Далее мои скрипты обращаются к API, получают JSON и изменяют\дополняют контент если требуется.
Что нового то предлагается, я в толк не возьму.
я ничего не убивал. Это ваша изначальная претензия к SPA, дескать, вот такой вот флоу и он вам не нравится. Мой ответ — не нравится вам этап загрузки скриптов, не загружайте. Вариантов всего два — загружать скрипты асинхронно или встроить их непосредственно в страницу. Оба этих варианты доступны без изобреиения новых сущностей.
>SSR появился сильно позже и как раз пытается решить те проблемы о которых я говорил.
Вы говорите о проблемах, которые сами же и выдумали, а теперь мужественно боретесь. На какой бы техлогии не был основан ваш сайт, все равно вы должны загрузить HTML самым первым этапом. Почему при использовании ангуляра этот инициализирующий HTML обязан быть белым квадратом — загадка сия есть, это вы просто выдумали.
>JAM стек предлагает отказаться от этого в пользу генерации контента разово, во вримя билда.
Я выше задал вопрос, на который мы сейчас и пытаемсёя получить ответ. Повторю его, каким образом я могу построить интернет магазин, если весь контент обязан быть известен на момент билда.
>Естественно это возможно далеко не всегда и не всегда имеет смысл.
Это никогда не имеет смыла. Так вообще работает весь интернет — контент не известен заранее. У сайтов есть админка, как правило. Персонал заказчика вносит изменения, получает их отражение на сайте. Пользователи работая с сайтом непрерывно изменяют данные, изменения непрерывно влияют на содержимое страницы. CMS на которых работает подавляющее большинство сайтов вообще нельзя постоить на статической основе, даже если страницы выглядят статичными. Я вам дал пример десятка сайтов с которыми работаю, дайте контрпример, покажите сайт, который может быть построен с использованием вашего чего-то там
>Это называется SSR.
Это любое занятие — выдумывать аббревиатуры.
> Вопрос терминологии и реализации.
Именно терминологии, а не реализации. Нет серверным приложениям, вроде так заявлялось? Оказывается, таки да, но давайте это называть немножечко по-другому, мы хотим написать десяток статей на эту тему и провести еще немножечко вебинаров.
Нет. Я сказал, что есть два варианта — встраивать скрипты или не встраивать. У вас варианта тоже два, и оба вам не нравятся. Вам не нравится флоу СПА приложения, потому что загружаются скрипты, и одновременно не нравится встраивание скриптов. Третьего варианта вы не дали. Так дайте. Ответ «надо чего-то там встраивать на этапе билда» не отвечает на вопрос встраивания или загрузки скриптов. Если же загрузка скриптов никак не относится к теме беседы, то нафига вы это приводите в качестве недостатка SPA.
>Вам уже ответили выше. Генерим статичные страницы для товаров, данные (цена/кол-во) подтягиваем асинхронно с клиента.
Да что это за бред в конце концов? Все данные о товаре диначеские. Приведите пример нединамических данных для товара. Если говорите про изображение, то оно в страницу не встраивается, встраивается ссылка. А ссылка вполне себе вещь динамическая. Страница со списком товаров тоже динамическая по природе своей.
>Это не правда. Сайты визитки, редко обвновляемые блоги, сайты с инструкциями и просто любым статичным контентом подходят.
Ну то есть, имеются никие крохи из всего айсберга, называемого веб. Эти проценты страничек Васи Пупкина с единицами посещений в день не представляются проблемой для серверной производительности. Делаются они на CMS и прекрасно кешируются. Проблемы которую решает статья «Нет чему-то там» не существует. Спасибо, я понял.
Да что это за бред в конце концов? Все данные о товаре диначеские. Приведите пример нединамических данных для товара. Если говорите про изображение, то оно в страницу не встраивается, встраивается ссылка. А ссылка вполне себе вещь динамическая.
И насколько это всё динамическое? Сколько раз в минуту может меняться описание одного товара? А в час? Ну хотя бы оно меняется каждый день? Как правило нет. В большинстве случаев товар описывается один раз и к нему прикрепляется одна или несколько фотографий. После этого такие данные могут оставаться неизменными до исчезновения товара с продажи.
Да, они размещаются в БД и, формально, остаются динамическими. Но по факту они практически статические и на их основе можно периодически (или по факту изменения данных) генерировать новые статические страницы, на которых через JS будут заполняться динамические данные.
Вам это шизофренией не кажется? Мне кажется.
Насколько часто меняется именно описание товара? И насколько страшно, что корректировка описания (скорее всего из-за ошибки в нём), будет отображаться на сайте не сию же секунду, а, например, на следующие сутки?
Чем плохо, если в блоге при создании/изменении статьи будет генерироваться статическая страница, а комментарии к неё будут грузиться динамически?
У вас есть данные, вы переживаете, что они медленно выгружаются, потому хотите генерить статику, но это не логично, вы по сути кешируете HTML, в то время, как можно закешировать данные о заказе, а то как он будет отображен, уже дело 10-е и не такое уж и долгое, особенно при серверном рендеринге, у вас же не хайлоады как у яндекса на поиске.
Итого, товар в кеше, сбрасываемый\обновляемый, если данные товара изменились, а рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко, скорость работы отличная, для 95% сайтов будет работать оптимально
рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко
Т.е. вы предлагаете всю (ОК, почти всю) БД держать в кеше?
Данные в любом случае будет занимать меньше места, чем хранение HTML. Тем более, можно делать хранение, только основных данных, выборка которых занимает основную часть времени.
Вариантов работы с кешом масса, можно всегда прогревать кеш заранее, а можно делать это только при первом обращении, или только определенных записей, решение индивидуально под проект и проблемы которые возникают с производительностью
Опять же, кеш не панацея, если что-то тупит, надо чинить там, а генерировать готовый шаблон на этапе сборки, как описано в статье это самое последнее, что можно придумать
Т.е. вы предлагаете всю (ОК, почти всю) БД держать в кеше?
Так тут предлагают ту же самую БД держать в кеше, только не в виде данных, а в виде HTML с внедренными данными.
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Это как раз таки не правильно, потому что если хранить уже конечный результат выходит огромное дублирование и оверхед.Дублирование чего? Если вы раз за разом отдаёте одно и то же, то ЭТО — дублирование и оверхед.
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx
В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по факту
Изменись у вас 1 атрибут, цена, артикул, да что угодно, вам нужно перерендерить 100500 шаблонов с этими данным. Это затратно по времени и в целом N+1 операция.Как у товара может поменяться артикул? Какие 100500 шаблонов мне вдруг придётся менять при изменении одного товара?
В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по фактуАга, только скажите, что у вашего сайта случается чаще — обновление основной информации на странице или просмотр? Если просмотров хотя бы не в 100 раз больше, чем обновлений, то да, подход не для вас.
А подход по напихиванию 100500 динамических элементов в рендереную на сервере страницу я видел на реддите — настолько у них всё «отлично», что там даже комментарии одной страницей не посмотреть, а местами и вообще не больше 2-3 за раз.
Как у товара может поменяться артикул? Какие 100500 шаблонов мне вдруг придётся менять при изменении одного товара?
Элементарно, товар же явно отображается не только на своем просмотре, а где-то есть превью, где-то еще что-то, везде пойди и перерендели большой HTML ради циферки
Если просмотров хотя бы не в 100 раз больше, чем обновлений, то да, подход не для вас.
Да хоть миллиард просмотров, это решается кешированием данных, а поверх уже оптимизацией рендеринга при необходимости. Redis и Nginx уже закроют основную нагрузку на эту работу
Тогда почему такой идеальны подход не используют все ресурсы? Он ведь так хорошо работает, так давай-те на все будем тулить генерацию HTML и вернемся к сайтам в 90-е
Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx…и он будет точно так же держать в кэше срендеренные файлы, только теперь вы ещё и контроль над инвалидацией потеряете.
P.S. Кстати, во многих серверных движках/CMS пре-рендеринг уже встроен. Причём, в достаточно динамических, вроде движков имиджборд.
Он будет держать в кеше страницы, которые пользователи посещали, и сбрасывать кеш по необходимости, когда он протухает, это не требует никаких вычислительных мощностей для сервера и никак не замедляет работу деплоев и тдОткуда он может знать, когда страница протухла, если это происходит в момент обновления данных в базе, о которой NGINX ни сном, ни духом? Разве что если делает каждый раз запрос к серверному коду для проверки, но тогда мы опять получаем, что и сервер нагружен, и логика какая-то дополнительная нужна (мы же не будем на каждый запрос заново генерировать страницу, верно? Иначе какой смысл в кэше)
Данные в БД обновились — сразу обновили кеш в редисе, и при необходимости дернули сброс закешированных данных в nginx для них. Как показывает практика, одного редиса достаточно.
Как минимум есть время жизни кешированной страницы, это разВ итоге страница будет перерисовываться безо всякой нужды — просто потому что срок истёк, хотя данные и не обновлялись.
если мы вдаемся в оптимизации, можно накручивать свою логику через скрипты, которые будут его сбрасыватьВот у нас нагрузка на сервер уже и не нулевая…
Данные в БД обновились — сразу обновили кеш в редисе, и при необходимости дернули сброс закешированных данных в nginxВот просто один в один то же самое, что просто дёрнуть рендеринг. Только ещё и две прослойки лишних в виду редиса и кеша nginx.
В итоге страница будет перерисовываться безо всякой нужды
И это по вашему проблема? С каких пор, рендеринг это проблема в 2021 году? Почему такие гиганты как VK, Facebook не делают HTML шаблоны на каждый пост?
Я бы очень хотел посмотреть, как они террабайты текста перегенеривают в шаблоны, да там харды менять нужно будет каждую неделю с такими нагрузками.
Вот у нас нагрузка на сервер уже и не нулевая…
Она никогда не будет нулевая, если у вас одностраничная визитка, да.
Вот просто один в один то же самое, что просто дёрнуть рендеринг. Только ещё и две прослойки лишних в виду редиса и кеша nginx.
Оставим к примеру редис. Не суть сейчас
У вас есть 2 ОТДЕЛЬНЫЕ операции — подготовка данных и вывод данных, данные всегда в кеше, их сброс это бекграунд операция, вам и посетитель вообще пофигу на этот механизм — сервер вернул данные — браузер срендерил страницу.
Приложение должно быть разбито на зоны ответственности, а если мешать все в одну кучу, разобьем все яйца…
Советую почитать Роберта Мартина — Чистая архитектура, для начала
И это по вашему проблема? С каких пор, рендеринг это проблема в 2021 году? Почему такие гиганты как VK, Facebook не делают HTML шаблоны на каждый пост?Во-первых, не шаблоны, а страницы. А во-вторых, откуда вы взяли, что не делают? А во-вторых, не могу посмотреть в их закрытые движки, но к слову про Википедию — в её движке файловый кэш, в который складываются отрендеренные страницы, есть.
Она никогда не будет нулевая, если у вас одностраничная визитка, да.Не будет нулевая если одностраничная визитка? Где-то тут у вас «не» пропущено?
данные всегда в кеше, их сброс это бекграунд операция, вам и посетитель вообще пофигу на этот механизм — сервер вернул данные — браузер срендерил страницу.А теперь просто подвинем это всё назад во времени — после обновления базы происходит сброс и перегенерация файлового кэша. В фоне, вы об этом точно так же ничего не знаете. Только теперь страница отдастся пользователю за микросекунды, потому что генерировать ничего не надо.
Приложение должно быть разбито на зоны ответственности, а если мешать все в одну кучу, разобьем все яйца…Именно — зачем вмешивать генерацию страницы в механизм отдачи HTML пользователю? Генерация страницы отдельно, отдача — отдельно.
Не будет нулевая если одностраничная визитка? Где-то тут у вас «не» пропущено?
Нет, видимо запутано выразился, 1 HTML страница будет работать без нагузки, а вот уже если их будет 1000, то нагрузка какая никакая все равно будет
А теперь просто подвинем это всё назад во времени — после обновления базы происходит сброс и перегенерация файлового кэша. В фоне, вы об этом точно так же ничего не знаете. Только теперь страница отдастся пользователю за микросекунды, потому что генерировать ничего не надо.
Потому что файловый кеш это медленно, если хранить, то хранить в памяти, вот это дает прирост скорости.
Именно — зачем вмешивать генерацию страницы в механизм отдачи HTML пользователю? Генерация страницы отдельно, отдача — отдельно.
Что мешает использовать тогда уже серверный рендеринг и его кеширование? Это абслютно тоже самое с точки зрения браузера, но без ненужных генераций шаблонов
Нет, видимо запутано выразился, 1 HTML страница будет работать без нагузки, а вот уже если их будет 1000, то нагрузка какая никакая все равно будетТак если все страницы статические (с т.з. сервера), и уже отрендерены, то какая нагрузка-то?
Потому что файловый кеш это медленно,Поэтому кэш NGINX — файловый, и быстрее всего он отдаёт статику с диска? Чтобы медленнее было?
Что мешает использовать тогда уже серверный рендеринг и его кеширование? Это абслютно тоже самое с точки зрения браузера, но без ненужных генераций шаблоновИменно, серверный рендеринг и кэширование в файлах. Никаких отдаваемых клиенту шаблонов, не знаю, откуда вы их берёте уже который раз — я говорю про отрендеренные страницы в виде HTML-файлов. С точки зрения веб-сервера (nginx) — это отдача статики, т.е., то, что он умеет делать быстрее всего.
1 — А не на калькуляторе ли хостится сайт?
2 — А оптимальный ли код?
3 — А оптимальная ли работа с базой?
И вот когда, из всех 3х пунктов можно сказать — да, соки выжаты по максимуму, можно уже начинать крутить кеши и прочие манипуляции
1 — А не на калькуляторе ли хостится сайт?1. А не платить ли мне больше денег, вместо того, чтобы иметь другую архитектуру?
2 — А оптимальный ли код?
3 — А оптимальная ли работа с базой?
2. А не сделал ли я серверный рендеринг на каждый запрос, вместо того, чтобы кэшировать ответы в виде статики?
3. А не зря ли я хожу в базу, когда мог отдавать статику?
1. А не платить ли мне больше денег, вместо того, чтобы иметь другую архитектуру?
В данном случае, слово «архитектуру» надо взять в кавычки. И сложно представить экономию в серевере для такой задачи, видимо я не в том вебе работаю.
А не сделал ли я серверный рендеринг на каждый запрос, вместо того, чтобы кэшировать ответы в виде статики?
Тут я только развести руками могу, я уже не знаю
А не зря ли я хожу в базу, когда мог отдавать статику?
А зачем мне вообще база? странички HTML? можно же просто 1 PDF\Word файл скинуть и вуаля, прайс лист готов
А зачем мне вообще база? странички HTML? можно же просто 1 PDF\Word файл скинуть и вуаля, прайс лист готовБаза — для отделения модели от представления. Генерация статики — для отделения генерации страниц от обработки запросов. А вы опять смешиваете в кучу отсутствие привычной вам архитектуры и отсутствие пользовательской функциональности.
Дублирование чего?
У всех защитников статических страничек сайт какой-то уж очень убогий получается. На словах то просто все — для каждой единицы товара генерируем страничку. Но это UX двадцатилетней давности. У вас нет всплывающих окон, тултипов, и вообще динамически подгружаемого контента. Я бы например хотел иметь список товаров с кратким описанием и возможность при нажатии мышкой получать более детальную информацию. Не перезагружая страницу как при царе Горохе, а используя современные удобные интерфейсы. Ну вот вам дублирование в чистом виде — вам одни и те же данные надо зашить в страницу дважды — к кратком виде в списке и подробном виде в скрытом диве.
У вас нет всплывающих окон, тултиповКакая тут связь? Почему их не должно быть? У нас же не чистый HTML без скриптов.
Я бы например хотел иметь список товаров с кратким описанием и возможность при нажатии мышкой получать более детальную информацию. Не перезагружая страницу как при царе Горохе, а используя современные удобные интерфейсы. Ну вот вам дублирование в чистом виде — вам одни и те же данные надо зашить в страницу дважды — к кратком виде в списке и подробном виде в скрытом диве.Вы пропускаете букву A в JAMstack? Никто не отбирает у вас AJAX и асинхронную подгрузку данных. Только серверный рендеринг в рантайме.
Слишком громкое название тогда "нет серверным приложениям" если сервер для АПИ всё равно нужен
Слишком громкое название тогда «нет серверным приложениям» если сервер для АПИ всё равно нуженПросто вы «серверными» понимаете «хоть как-то использующие сервер», а автор мог иметь в виду, например, «использующие только сервер» или «исполняемые преимущественно на сервере».
Сам факт того, что данные размещены в БД делает их строго динамическими. Сколько бы раз в минуту/час/год данные не обновлялись, с точки зрения сайта они обновляются в непредсказуемый момент времени.У вас сайт отдельно от CMS существует, что ли? Или пользователи руками в базе записи в таблицах правят? Почему вдруг этот момент непредсказуемый, если вы сами этот момент в своём приложении и обрабатываете, когда данные ы БД пишете? У вас же сайт, наверное, не простой интерфейс к чьей-то чужой БД?
У вас сайт отдельно от CMS существует, что ли?
Представьте себе! У меня есть сайт, у меня есть мобильное приложение, а еще у меня есть бухгалтерская программа, и весь этот зоопарк манипулирует данными в одной базе.
(микро)сервис, владеющий базой.
(Микро)сервис, который монополизирует работу с базой, в которую сейчас стучится несколько приложений, и хорошо если только одно на запись.
Чтобы трём приложениям сделать запросы в БД им всем нужно знать схему/ Иными словами, изменения в схеме нужно дублировать в коде всех приложений. Спрятав базу за сервисом (сделанным с нуля или преобразованным из одного из приложений) мы избавляемся от этого — минорные изменения схемы не повлияют на публичный API сервиса.
Если вашем мире серверные приложения в талицы не ходят и вообще только с хранимками общаются, то сложно вам будет объяснить проблемы, когда не одно, а несколько приложений ходят в базу и выполняют там напрямую UPDATE запросы. Хотя обвешаться хранимками, запретив прямой доступ к таблицам всем, и выставить микросервис — решения для одной и той же проблемы, по сути. Просто разные решения. Одним проектам подходит одни, другим — другие. В том числе и смотря какие люди работают на проекте. Я вот уйду с любого проекта как только там решат ключевую логику переносить в хранимки.
P.S. Транзакционность по http нормально делать: один запрос — одна транзакция. Как каждый вызов хранимки в транзакцию обернуть. Да и не говорил я про http.
P.P.S. Микро я везде в скобках ставил, чтобы подчеркнуть что оно не принципиально, а вы с ним так...
ээээ? Чтобы записать данные в БД нужен микросервис? А чтобы данные микросервису передать, нужен еще один микросервис? А я не понял. А зачем? Чем запрос в микросервис лучше запроса сразу в СУБД?
Микросервис просто дублирующий запись в БД — нет, не нужен.
А вот если он попутно проверяет права доступа пользователя, защищает БД от атак из прямого подключения к интернету, преобразует данные в различные форматы и пр. и т.п. — то да, польза от микросервиса есть.
Вот у меня есть корпоративная система написанная на JAVA EE, развернутая на WebLogic и коннектящаяся к Oracle. Теперь я хочу сделать сайт, который будет использовать ту же базу данных и выбираю технологию. Мне рекламируют некий JAM
Вы выбрали заведомо неподходящие начальные условия.
Откуда это явствует? Ну правда, откуда этот сервис может знать, какие именно данные изменились в БД?Ну, если у вас всё на хранимках и триггерах, то запросто оно по триггеру на апдейт интересующих полей будет проставлять соответствующие флаги. Опять же, версионность записей у вас в БД не ведётся? Для тех же оптимистичных апдейтов? Флаг dirty/synced или таймстемп последнего изменения нигде не проставляется?
P.S. А в вашей архитектуре с n приложений, пишущих в общую базу — в каждом свой балансировщик, проверка прав, етц?
Ради чего «предгенерация» ради названия товара и цвета шапки?Ради название, описания, артикула, характеристик, хлебных крошек, меню, хедера, футера, разметки под эти и остальные блоки, карты магазинов, ссылок на скрипты и стили, аналитики и т.д…
Комментарии и отзывы, кстати, всё равно, обычно, предмодерируются, а цены меняются не руками в базе, а через CMS, которая вполне может запускать перегенерацию страницы. (А если прямо хочется руками в базе править, то можно повесить триггеры, помечающие данные «грязными»).
Если же вы про отдельные цены с персональными скидками, то такие чаще показываются уже в корзине. Которая рисуется джаваскриптом поверх готовой страницы.
Да, серверный код останется, но только там, где он нужен, а не на каждой странице, перерисовывая с нуля всю разметку на каждый запрос.
Механизм рендеринга 1 — данных много.
А так получается мы делаем дубликацию шаблонов с заполненными данным, вместо того, чтобы сайт весил 500 мб в вакууме, он будет весить N на M+k, где N размер 1 шаблона и M количество шаблонов и k размер данных
я хотел бы посмотреть, как вы ту же например википедию будете хранить таким образом и сколько места у вас займет
вместо того, чтобы сайт весил 500 мб в вакууме, он будет весить N на M+k, где N размер 1 шаблона и M количество шаблонов и k размер данныхУ вас 500мб одних шаблонов и текста в БД? Серьёзно? Это больше, чем в большинстве языковых версий Википедии.
Не важно сколько весят все шаблоны, важно то, что при генерации страниц, зря занимается дискове место на сотни, а то и тысячи файлов, что тоже рождает свои проблемы, по деплою, перегенерации
Вот представьте, у вас магазин, в нем 10 000 товаров. Какой-то менеджер делает импорт товаров, новых, 2 000 и изменяет еще 1 000 старых, нужно просто так, сделать генерацию 3-х тысяч шаблонов + шаблоны связанных страниц. Скрыть товар из продажи, что, дропать HTML шаблон?
Лишние и бесполезные действия. Спор не уместен, не сможете убедить, что каждый раз дублировать данные это гениальное решение.
Это были абстрактные цифры, потому и написал, что в вакууме.Вот только проблема в том, что html-разметка в размере большинства сайтов занимает, наверное, второе место с конца. Сразу после robots.txt
Не важно сколько весят все шаблоны, важно то, что при генерации страниц, зря занимается дискове место на сотни, а то и тысячи файлов, что тоже рождает свои проблемы, по деплою, перегенерации
Вот представьте, у вас магазин, в нем 10 000 товаров. Какой-то менеджер делает импорт товаров, новых, 2 000 и изменяет еще 1 000 старых, нужно просто так, сделать генерацию 3-х тысяч шаблонов + шаблоны связанных страниц.3 тысяч страниц по одному шаблону. Вы же сами говоите, что это миллисекунды занимает. Если так уж не нравится, подождать целых 10 секунд, то можно и отложенный рендеринг сделать — при первом обращении.
Скрыть товар из продажи, что, дропать HTML шаблон?Шаблон-то зачем? Одну страницу. Удалять или обновлять (ставить метку «нет в продаж»), или просто в подгружаемой цене это выдать — как угодно.
3 тысяч страниц по одному шаблону. Вы же сами говоите, что это миллисекунды занимает. Если так уж не нравится, подождать целых 10 секунд, то можно и отложенный рендеринг сделать — при первом обращении.
Только зачем хранить 3 тыс страниц, если достаточно хранить шаблон?
Абстрактно ваш шабло 1 КБ, значит вы на ровном месте сделали 3000 КБ только за счет их дублирования. И спрашивается вопрос — зачем?
Миллисекунды занимает рендаринг шаблона в браузере, каждый рендеринг, перерендеринг шаблона это безсмысленная нагрузка на диск, что черевато проблемами + это нагрузка. В отличии от хранения данных в памяти.
Одну страницу. Удалять или обновлять
Только вот это лишние действие
Вот послушав такие разговоры, я не удивлен, что большинство ресурсов, особенно на CMS тупят как адовый ад
Только зачем хранить 3 тыс страниц, если достаточно хранить шаблон?Затем, что все эти пре-рендеренные запросы всё равно будут занимать места меньше, чем один только рантайм редиса. И меньше, чем одна HD-фотография в карточке товара.
Абстрактно ваш шабло 1 КБ, значит вы на ровном месте сделали 3000 КБ только за счет их дублирования. И спрашивается вопрос — зачем?
Миллисекунды занимает рендаринг шаблона в браузереУже и в браузере, а не на сервере? И на телефонах? А то, что браузеры файлы тоже в дисковый кэш кладут — вы в курсе?
Только вот это лишние действиеЛишнее действие CMS? Ну, пометила бы она то же самое в базе, какая разница-то?
Вот послушав такие разговоры, я не удивлен, что большинство ресурсов, особенно на CMS тупят как адовый адПотому что на каждое действие ре-рендеринг делают? Давайте без переходов на личности, хорошо?
И меньше, чем одна HD-фотография в карточке товара.
Ну да, ну да…
А ничего, что картинка в данных это только ссылка на картинку? а картинки, как раз относятся к статике и кешируются веб-сервером (Nginx) так что этот пример в корни неправильный.
Уже и в браузере, а не на сервере? И на телефонах? А то, что браузеры файлы тоже в дисковый кэш кладут — вы в курсе?
Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.
Лишнее действие CMS? Ну, пометила бы она то же самое в базе, какая разница-то?
Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.
Потому что на каждое действие ре-рендеринг делают? Давайте без переходов на личности, хорошо?
Кстати тут не было перехода на личности, это скорее было сожаление по факту, т.к. часто сталкиваюсь с проблемами на сайтах, написанных с использованием CMS и возможно каких-то велосипедов. Так что тут извинения, если не так понято.
Нет, потому что изобретаются неправильные решения, которые выдаются за архитектуру, хотя это костыли и не желание разбираться в конечной проблеме, когда она есть.
О кстати, еще в копилку перерендеринга — фронтещик или кто-то решил шаблон поменять, о нет, нам надо сделать перегенерацию всех товаров, потому что в блоке цены добавился новый CSS класс…
А ничего, что картинка в данных это только ссылка на картинку?И что? Вы же про место на диске говорили? Или к чему был этот пассаж про «размер сайта»?
Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.Что? Вы уже совсем ёрничаете. Речь шла о серверном рендеринге, а вы, почему-то, вдруг про генерацию в браузере начали писать. Теперь ещё и вот это…
Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.Вы предлагаете данные и метаданные в разных местах хранить, или что? Чем ваши хуки на обновление кэша отличаются от хуков на удаление файла?
Нет, потому что изобретаются неправильные решения, которые выдаются за архитектуру, хотя это костыли и не желание разбираться в конечной проблеме, когда она есть.Решения давно изобретены, называются «файловый кэш», и он есть встроенный в куче движков.
яснопонятно. Бизнес любит когда программисты делают не то что хочет этот самый бизнес, а то что «чаще» и «обычно».Ну, если бизнес требует править базу прямо руками, то бог им судья.
директор: Наши маркетологи тут прикинули, давайте выводить цены для пользователей с индивидуальными скидками на всех страницахОу, вы так пишете, будто это нереализуемо. Собственно, точно так же реализуемо на клиенте, в рантайме. Просто цены будут, например, подсчитываться JS'ом уже после загрузки разметки страницы. Причём, пользователь может об этом и не узнать.
программист: Знаете, скидки чаще в корзинах
А бывает по другому? но мы все равно назовем это безсервеный рендеринг? Потому что сервер все же у нас есть? логика то в чем?Потому что РЕНДЕРИНГ будет делать НЕ СЕРВЕР. Никто же не говорил «безсерверный сайт»?
как там кэш осуществляется, предварительной генерацией страниц в html файлики или по запросу байтиками в редисе, какая разницаРазница в том, что генерация может осуществляться не кодом сайта вообще, а кодом CMS/деплой-скрипта. Ну вот не будет в серверном коде сайта кода, генерирующего HTML-разметку.
допустим сервер на golang, в качестве шаблонного движка используется quicktemplate, он все шаблоны в бинарник загоняет.Разница в том, что ваш код будет ходить в базу даже за данными, которые заведомо не менялись, парсить их и трансформировать соответствующим образом в разметку. Или он у вас сырой ответ от БД прямо байт в байт отдаёт посреди HTML?
Так вот, с какой стати прочитать страницы index.html и home.html с диска и отдать их будет быстрей чем сделать конкатенацию строк
header + indexcontent + footer, все уже в бинаре зашито, а за контентом в базу и так и так идти.
поменяли цену на странице А, запустили перегерацию тысячи связанных страниц, потом поменяли на странице Б и запустили снова перегенерацию тысячи страниц, 900 из которых совпадают с первыми. А не эффективный ли вы менеджер?Зачем у вас одна и та же одна цена отображается на тысяче страниц?
Итог: У нас есть сервер приложений, у нас есть кэш. И мы почему-то называем это «нет серверам». без которых на самом деле ничего работать не будет.Если уж мы генерируем страницы при обновлении данных в CMS, то и кода этого на сайте быть не будет. Он в CMS, а не на сайте. И в отдаче контента клиентам не участвует.
а как вобще связаноНу, вы же как-то из «чаще» и «обычно» вывели «невозможно».
Бизнес:«Я хочу чтоб были скидки»
Программист:«Нет мы их делать не будем»
с каким-то прямым хождением в базу, почему вобще база вызывает такой страх, что она приплетается к месту и не к месту?
(вообще — да, забыл, почему я именно к этой цитате этот ответ приписал).
1)баннер с «Люди смотревшие это, так же смотрят»Ну, и пусть подгружается динамически. С API придёт список ID связанных товаров, а для которых подгрузятся мини-карточки или просто данные для клиентского рендеринга, если там мало разметки.
2)Тысячи страниц фильтра «ТВ с диагональю до 50» «ТВ с диагональю до 49»… а наш целевой 30 и везде попадет.Воу, а вы и страницы результатов поиска/фильтрации предполали статикой делать? Все возможные комбинации включая все возможные буквы в поиске? Ну, уж это-то точно динамические данные и работа с API.
Еще раз, что значит не участвует? Купить товар можно без сервера? Ради чего заниматься перегенерацией тысяч страниц, если от сервера не избавились?В обслуживании read-only активности клиентов он не участвует, в результате нагрузка на него будет только от активных действий типа покупки или поиска, которых, обычно, на порядки меньше.
что знач сырой прям в HTML, там вобще может быть не html, а предобработанные данные.То и значит, что отдача байтового потока — задача на порядки более простая, чем формирование разметки на основании данных, и отдача уже её. Это же ответ на
Так вот, с какой стати прочитать страницы index.html и home.html с диска и отдать их будет быстрей чем сделать конкатенацию строк
header + indexcontent + footer, все уже в бинаре зашито, а за контентом в базу и так и так идти.
Если с базы мы тянем хоть что-то, хоть крохотулечку данных, запрос почти моментальный, вытягиваем допустим цены. что мешает вытянуть еще и название и артикул и описание.Так в том и суть, что цены не меняются непредсказуемо, соответственно, и обновлять ничего до обновления цен не нужно, отдаём готовую страницу и ни базу, ни рендеринг, ни парсинг, ни обработку не трогаем.
Если же будет отдельный функционал, для которого нужна база, то это уже полностью срендеренная страница пойдёт в API endpoint, что не только можно отложить, снизив TFFB в десятки раз, но и не будет задействовать генерацию целой страницы всяких разметок на сервере.
я верю что есть такие сайты, только интернет магазины не имеют к ним отношения.У вас какие-то странные интернет-магазины, в которых все данные всё время непрерывно меняются. На всех, какие я видел, 95%-99% разметки страницы не меняется чаще раза в день. Оставшиеся же 1-5% спокойно себе загружаются асинхронно AJAX'ом.
Пользователь купил последний экземпляр товара,Как часто такое происходит для товара? Неужели хотя бы несколько раз в день?
нам после действий пользователя надо пересчитать все страницы на которых как-то фигурировал этот товар? А найти эти страницы это очень сложная задача.Он нигде в разметке не должен фигурировать, кроме своей карточки (и мини-карточки, если такая есть). Все остальные места, где он фигурирует — это результат получения с сервера его ID и подгрузки AJAX'ом соответствующей карточки.
Так оно и щас так, без jamstack.У вас только 1% загружаемых данных не генерируются в момент запроса? Так поздравляю, у вас JAM.
А че это мы только 1 вариант изменений выдернули из контекста и говорим «а это не часто случается», а как на счет остальных вариантов, оставил комент/оценку, просто своим просмотром поднял автоматический рейтинг интересности?Вотэбаутизм какой-то. А что это вы сами из моей «простыни» ответов только на несколько строк отвечаете, при том, что сами мне предъявляете, что я не на всё ответил?
Я, нет конечно, а вот вы поначалу да, но после вопросов… «Ну это мы с апи дернем, а это динамически сгенерируем, но сервера нам конечно не нужны, да»Где это я говорил, что сервера не нужны? Зачем вы мне приписываете то, чего я не говорил?
Букинг считается за интернет магазин где все время меняются страницы? «этот номер сейчас смотрят 3 человека» «Этот номер только что забронировали».Отличный пример! А теперь скажите — пришли ли эти данные в составе страницы, или загружены аяксом в виде JSON из API?
На любом современно интернет магазине есть динамичсекие данные.Есть, но во всех местах, где эти данные действительно часто меняются — они подгружаются аяксом из API, а не рендерятся в разметку самой страницы.
сам рендеринг не занимает ничегоТакое ничего, что люди от него за кэширующими прокси и CDN прячутся.
Эти проценты страничек Васи Пупкина с единицами посещений в день не представляются проблемой для серверной производительности.
Так там потому и единицы посещений в день, что они не на JAM-е! А были бы на JAM-е, там бы отклик был на 2мс ниже и сайт бы смыло волной трафика. Или нет.
Я выше задал вопрос, на который мы сейчас и пытаемсёя получить ответ. Повторю его, каким образом я могу построить интернет магазин, если весь контент обязан быть известен на момент билда.
Если учет ведется не на сайте интернет-магазина, а в какой нибудь специализированной системе, например, 1С или т.п., то у вас присутствует регулярная подгрузка новых товаров.
В этот момент можно перебилдить статические страницы каталога товаров интернет-магазина.
Делал так в продакшене. Билд на офисном внутреннем сервере, после чего деплой на веб-сервер.
Для пользователя интернет-магазина — сплошное удобство:
Веб-сайт обновляется мгновенно.
Страницы загружаются мгновенно.
Проблема медленного рендера давно решена кешированием. Да, не всегда спасает, но деплой 5 часовой 150тыс. страниц Вас тут тоже не сильно спасёт, если поменяв немного лейаут нужно будет их прегенерить заного.
Генерить темплейты в билде не актуально по одной простой причине — слишком быстро всё меняется, быстрые релизы — тоже для многих важны. С этим бегемотом это невозможно.
Блог или новостник — с ростом кол-ва страниц будет увеличиваться длительность билда, хорошо если пропорционально. Если паралелить — этож какой билд сервер нужен чтоб 20к страниц сгенерить.
А еще такой момент — автор, ты видел как выглядит перерисовка страницы, когда рендерится темплейт без данных, как потом весело всё скачет когда данные подставляются. Эта проблема имеет пути решения, но они не тривиальны.
И если в SPA приложении у тебя есть циклы жизни приложения и соответствующий API лдя работы с различными ивентами — то у тебя тут только статика, тонна проверок и спагетти код чтобы контролировать все состояния.
Для личного лендинга, который обновляется раз в три года — может остановится на любой генераторе статики, а еще лучше собрать ручками, потренироваться, так сказать.
Еще один коммент по поводу статика на запрос или статика при билде:
у тебя есть 20к страниц, деплой раз в неделю. Предположим 50% страниц на которые заходят 0-1 посетитель в месяц. Сколько времени, ресурсов и сколько ненужных данных будет сгенерировано за этот месяц? По этому — у тебя есть «генератор» ответа и кеширующий механизм, в котором, помимо того чтобы хранить тот же «сгенерированый контент» ты еще можешь управлять точечно «сроком годности» этого контента. Устарел — сгенерили заного, по запросу.
Такое впечатление, что кто-то не разобравшись в доках и напилив сервисы отвечающие по 10 секунд пытается придумать супер решение. Решение, ИМХО, очень нишевое.
А деплои… всё равно будут сложные, т.к. нужно версионирование и откат на предыдущие версии, так что еще и за дисковое пространство надо будет накинуть.
А API так вообще по-старинке придётся поддерживать.
А еще такой момент — автор, ты видел как выглядит перерисовка страницы, когда рендерится темплейт без данных, как потом весело всё скачет когда данные подставляются.Если у вас часть данных не отдаётся дольше, чем все, включая рендеринг, то на время загрузки можно просто крутить спиннер и ничего не показывать.
И если в SPA приложении у тебя есть циклы жизни приложения и соответствующий API лдя работы с различными ивентами — то у тебя тут только статика, тонна проверок и спагетти код чтобы контролировать все состояния.А почему, если не SPA, то сразу спагетти-код и вот это вот всё? Какая связь? Есть же даже и фреймворки готовые примерно к этому, типа React Static.
По этому — у тебя есть «генератор» ответа и кеширующий механизм, в котором, помимо того чтобы хранить тот же «сгенерированый контент» ты еще можешь управлять точечно «сроком годности» этого контента. Устарел — сгенерили заного, по запросу.Ну, и отлично? Генерация по запросу готовых HTML-страниц, обновление кэша через удаление файла из файлового кэша. При этом, пока страницы не обновляются, всё будет происходить как описано у автора.
2) Реактивность, если это не SPA, обычно заканчивается кучей невнятного кода. Как и любые попытки посредственных разработчиков создать собственное решения с блэкджеком… ту не конкретно к автору или кому-то, просто так случается. Почти всегда.
3) Есть сомнения насчет «удалить файл из файлового кэша». А новый мы как создадим? А если я правильно понял автора — то нам нужно запустить билд. Билдить приложение, чтобы почистить кэш — это перебор. Если мы генерируем статику точечно… зачем переизобретать кэш (тот же Varnish), который будет работать медленнее (память быстрее FS). Опять же — как нужно автоматизировать весь процесс билда и деплоя, написать обвязку для очистки и новой генерации, сколько железных ресурсов на это нужно — даже думать не хочется.
П.С. Статика есть статика. Где-то — подходит, но в нашем динамичном мире — достаточно редко. Массово применять такой подход — скорее всего не получится, или будет представлять из себя кучу костылей. А для тех, кто боится серверов, деплоев и прочее — есть решения типа serverless, когда всё окружение работает «почти без участия разработчика», в том числе горизонтальное масштабирование. До поры, до времени, конечно :)
1) Ну сначала нам нужно загрузить основную разметку, скрипты и запустить их — чтобы подтянуть данные. Соответственно нужны какие-то «наполнители». Тот же крутящийся круг — круто, но когда данные подтягиваются с разных API и скорость их загрузки разная — тут или ждать пока мы получим всёИ в чём проблема-то? Серверную страницу вы столько же времени и ждали бы — пока все API ответят.
Контролировать рендер — всё равно нужно скриптами. Так мы приходи к уже устоявшемуся SPA.Почему если скрипты, то сразу SPA-то?
2) Реактивность, если это не SPA, обычно заканчивается кучей невнятного кода. Как и любые попытки посредственных разработчиков создать собственное решения с блэкджеком… ту не конкретно к автору или кому-то, просто так случается. Почти всегда.SPA — это всего лишь сайт с одной точкой входа. Никто не мешает вам тот же Реакт использовать хоть на тысяче страниц. Посмотрите, например, на React Static. Он специально для этого и написан.
Если мы генерируем статику точечно… зачем переизобретать кэш (тот же Varnish), который будет работать медленнее (память быстрее FS).Только вот кэш NGINX, например — именно файловый. И в состоянии простоя не потребляет ни ЦП ни памяти, переживает перезагрузки и не требует никакого доп. ПО для отдачи его. А кэш в той же MediaWiki — файловый из коробки.
Опять же — как нужно автоматизировать весь процесс билда и деплоя, написать обвязку для очистки и новой генерации, сколько железных ресурсов на это нужно — даже думать не хочется.Вы так пишете, как будто про прогрев кэша никто не слышал, и это автора поста его только что придумал, заодно изобретя огонь и колесо. Особенно интересно, что вы боитесь задачи очистки файлового кэша: на секундочку, заключается она в банальном очистки папки с ним.
А для тех, кто боится серверов, деплоев и прочееЭто вы же выше написали, что деплоя боитесь =)
А я не понял. Вот, допустим, у нас есть интернет магазин. Есть страница со списком товаров, для каждой единицы товара отображается доступность товара на складе. То есть у нас есть статический шаблон страницы, и есть волатильная информация, которая натягивается поверх шаблона. Натягивание информации на шаблон можно организовать на сервере — серверный рендеринг, или на клиенте. По такому принципу работают, как мне кажется, 95% сайтов. Объясните, пожалуйста, как я могу во время билда чего бы то ни было встроить информацию в страницу, если информация сама по себе не статична
Делал интернет-магазин на статике.
Все страницы с товаров регулярно обновлялись по мере прихода новых наименований товаров.
Остатки товаров отображались с помощью API. То есть при загрузке страницы с товаров в браузер пользователя кнопочка «Купить» или надпись «Нет в наличие» определялась автоматом, хотя всё прочее содержимое — статическое.
Корзина, разумеется, тоже динамически контент свой показывала пользователю. Так же — статическая страница корзины без контента. А сами наименование товаров, положенные пользователем в корзину, отображались динамически.
Опять же, если контент уже скачан, он возьмётся из локального кеша.
Т.е. берем вариант №1, делим на компоненты, закладываем контент, например, в локальный json и… собираем статику. При необходимости что-то изменить или собрать приложение, просто вносим нужные изменения и пересобираем проект.
Допустим, изменилось описание одного статического элемента (товара), и мы условно "разворачиваем веб сервер заново" (пересобираем проект). Спасибо, но нет.
Описание одного товара может отображаться на каждой странице сайта
Ну, и, кстати, иметь для каждого товара кроме полной карточки ещё и её мини-версию для подгрузки на другие страницы — тоже виданная практика.
Флагманская модель, баннер с которой бизнес хочет поместить на каждую страницу.
Ну вот все страницы со ссылкой надо перегенерировать, да, когда картинку надо поменять?
закэшируется — не страшно?
Придумываем себе проблемы и героически их решаем? )
Так один из способов борьбы с нежелательным кэшированием картинок как раз перегенерации ссылок на них. На фронтенде я бы сказал, что основной
Так один из способов борьбы с нежелательным кэшированием картинок как раз перегенерации ссылок на них. На фронтенде я бы сказал, что основнойТак ведь там, обычно, меняют незначимую часть ссылки, добавляя избыточный параметр в search-часть. В случае статики это всё продолжит отлично работать.
Так ссылку надо перегенерировать всё равно по всему сайту. А если надо, то зачем ограничиваться только search частью, если можно сделать человеко/SE понятное cool_model.jpg, а не переиспользовать 1.jpg тысячи раз?
Так ссылку надо перегенерировать всё равно по всему сайту.Видимо, я не так понял предыдущий комментарий. Зачем менять ссылку в разметке? Нормально настроенный сервер и так вернёт не 304, а если у нас неконтролируемые прокси, игнорирующие ETag и If-Modified-Since, и большое желание всегда получать свежую версию, то у нас же есть JS. Которым можно отлично дописывать значение Math.random() к URLу. А если мы для обхода кэша что-то меняем в отдаваемой сервером разметке, то это уже не «на фронте», это костыльная серверная логика.
А если надо, то зачем ограничиваться только search частью, если можно сделать человеко/SE понятное cool_model.jpg, а не переиспользовать 1.jpg тысячи раз?Опять же, что мешает это делать в случае статической разметки? Будет top_banner.jpg (<img src="/img/top_banner.jpg?rnd=0.68851461684872">) Или вы каждому еженедельному баннеру хотите «интересное» имя присваивать?
У нас есть желание не слать/получать лишних запросов с 304, один раз получил и хранит "вечно", пока кэш не почистят или не вытесняется из него
И, да, каждому
У нас есть желание не слать/получать лишних запросов с 304, один раз получил и хранит «вечно», пока кэш не почистят или не вытесняется из негоОчищать кэш когда кэш очистят — это тавтология. 304 — это и есть ответ «кэш всё ещё актуален». Вы же предлагаете всё время заново получать данные с текущим урлом вместо того, чтобы получать 304 по старому урлу.
Я предлагаю только один раз получать данные типа картинок, стилей и скриптов и не спрашивать у сервера при показе каждой страницы, а не изменилась ли они. 304 — для html оставьте
Expires: never
Хранить список и при деплое инкрментит суффикс _N или типа того
То, что вы описываете — это SSG. JAMStack пребилдит в основном Markup и может делать пререндеринг страниц, но потом охотно использует API (который в свою очередь общается с базой или Headless CMS) и без труда рендерит на клиенте при помощи JavaScript (после регидрации обычно только так и рендерится). Собственно из подчеркнутых символов и формируется JAM. Кстати, вам до этого задали хороший вопрос, попробуйте добавить в свой пример с блогом комментарии пользователей.
Но ведь у вас всё равно в итоге получился не JAMstack. Вы всё ещё используете чисто второй подход скатываясь к первому, только рендер перенесли с on-prem на этап сборки. В итоге на выходе у вас только статическая разметка (пусть и сгенерированная). Это путь всевозможных статических генераторов и только часть JAMstack, даже не половина, а скорее треть.
Чтобы получился действительно настоящий JAMstack нужно скрестить все 3 варианта. Причём даже в статье расшифровка приведена JavaScript API Markup. Т.е. к вашему варианту нужно ещё добавить сервер с API (и вот оно расхождение в статье) и клиентский JavaScript код, тогда у вас будет действительно JAMstack.
Фактически сайты на React/Vue/etc, если используют API, гидрацию и будут собирать страницы в статику именно на этапе сборки — настоящий JAMstack.
Чтобы понять что такое JAMstack, оставлю ссылку на JAMstack.wtf. А вообще всё это довольно олдскульно, даже JAMstack существует далеко не 4 года и не 8.
В итоге на статических сайтах с 1000+ страницами время билда может доходить до получаса. Потому что даже в случае изменении одной страницы новый билд запускается для всего сайта.
Например контент менеджеру надо было добавить пару новых блоков в блоге. Он идет в админку JAMstack CMS, делает правки и отправляет измененную статью на публикацию. Теперь, для того, чтобы убедиться, что изменения дошли до продакшена, он должен полчаса жить в режиме «не забудь проверить продакшен». Вроде, как можно поставить напоминалку и т.д., но по сути в эти полчаса ничем продуктивным заниматься невозможно. А если он что то пропустил, забыл или заметил опечатку? Снова билд на полчаса.
Если несколько менеджеров работают над разными статьями, то каждый будет запускать процесс деплоя для всего сайта.
Разные CMS предлагают различные варианты решения этой проблемы. Gatsby вот например предлагает Incremental Builds, которые те же полчаса могут превратить в 10 сек (согласно рекламе). Но эта опция доступна только на их платном Gatsby Cloud.
Статически сгенерированные сайты определенно несут преимущества для конечного пользователя. Но стоит помнить, что у всего есть своя цена.
На самом деле всё зависит от подхода, можно каждый раз генерировать полностью целый сайт, а можно перегенерировать только изменившиеся страницы (Incremental Build). Это конечно ещё и от инструментов зависит.
Вообще стоит сказать, что JAMstack может быть и без генераторов на самом деле. Если у вас собранная руками html страничка и есть как клиентский JavaScript, так и запросы к API — вы уже используете JAMstack. Даже если страница фактически будет тупо скелетоном это всё ещё JAMstack, хотя больше продвигается "прогрессивный" подход. Тут важно ещё не забывать про клиентскую сторону — мегабайты кода. Всё это всё ещё нужно оптимизировать.
Статически сгенерированные сайты определенно несут преимущества для конечного пользователя. Но стоит помнить, что у всего есть своя цена.
А вот это в рамочку. В зависимости от подхода к JAMstack вы будете платить временем и объёмом хранилища.
Вау, так это же практически описание opcache + memchaced!
Перезагружать статические страницы при переходе от одной к другой, где меняется только текст — долго, гораздо лучше использовать кеширование запросов (та же статья в html) + обновление содержимого. Этим вполне успешно занимается livewire или react и ему подобные.
Пользуетесь ли вы JAMstack?
Нет ибо LEAMP + Bitrix наше всё :) !
необходимые для приведения приложения в работоспособное состояние, с сервера в браузер.
Сказано так как будто это что то хорошее
Тем более, перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернета или компьютера пользователей.
перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернетаВо-первых, по сравнению с SPA, тут нагрузка перекладывается на билд. Во-вторых, не наоборот ли, в случае слабого интернета как раз меньше запросов придётся делать?
Причем в случае клиентского, с бекенда придут только данные, и скорее всего, их трафику явно будет меньше, чем HTML разметка.
Ну и опять же, подход описанный в статье, это чисто для статических сайтов.
стесняюсь спросить, а как получить данные из api или бд, во время генерации, если нет серверного приложения с логикой и данными?.. мне кажется описан подход SPA(singe page application), где приложение можно самим с сервера отдавать как статику или в cdn положить.
стесняюсь спросить, а как получить данные из api или бд, во время генерации, если нет серверного приложения с логикой и данными?..Так приложение у вас будет, но оно будет генерировать статические страницы при билде, а не обрабатывать запросы клиентов.
мне кажется описан подход SPA(singe page application), где приложение можно самим с сервера отдавать как статику или в cdn положить.В SPA страница одна (Single page), т.е., один HTML-файл, а вся разметка генерируется или подменяется динамически на клиенте. Тут же предлагают всю разметку генерировать заранее. Соответсственно, страниц может быть много.
Reply
SPA тоже JAMstack, т.к. есть JavaScript, есть API и есть Markup (пусть и в виде одной страницы).
С сайта JAMstack.wtf:
JavaScript
Dynamic functionalities are handled by JavaScript. There is no restriction on which framework or library you must use.
APIs
Server side operations are abstracted into reusable APIs and accessed over HTTPS with JavaScript. These can be third party services or your custom function.
Markup
Websites are served as static HTML files. These can be generated from source files, such as Markdown, using a Static Site Generator.
Генераторы статичных сайтов это не что-то новое. Если вся суть подхода завязана на применении CDN то это выглядит слабовато для подачи сабжа как новой парадигмы. К тому же сам факт того что технология практически не дожила до наших дней говорит о многом.
Автор сам запутался во всех "новых" словах которые он узнал за последние пару лет.
- В начале он говорит нет серверам и на середине статьи говорит, а вот JAMstack (у которого на минуточку API это сервера). Т.е. он сам себе противоречит.
- SPA/MPA/PWA/CRA/etc, React/Vue/etc. и т.д. и т.п. Если они используют статичные HTML страницы (даже если она одна), используют JavaScript (а всё перечисленное использует его), используют API (а многие всё же делают запросы к API) — всё это JAMstack.
Сам JAMstack далеко не новый, название и реклама да, подход нет. И он не умирал и не умирает, а живёт и процветает, подстраиваясь под 5 лет эволюции веба (на самом деле 10 лет, а если честнее ещё больше). Ключевые JAM: JavaScript API Markup никуда не пропадали.
Была в свое время (возможно и сейчас работает) техника рендера страниц из xml+xslt, т. е. По сути вам нужно из api получить xml преобразовать его с помощью xslt в html, и все собирается на стороне клиента "без сервера", как бы употребил автор статьи. Но подход оказался совсем не удобным)
Тезисов тупее чем в этой статье ещё поискать если честно
Проблема такой технологии в том, что она решает частный случай. И если будет хотя бы 1% реально динамической информации, которую нужно отдавать в реальном времени, то придется параллельно с придуманной технологией использовать классические методы.Там есть запросы к API (буква А в JAM). Или вы в реальном времени страницу перезагружать с сервера предлагаете?
Вот я хожу по сайтам. Скорость меня устаивает. Ну, то есть, если делать сайты/приложения нормально, оптимизировать запросы, кешировать и подобные фишки, все будет ок и без данного велосипедаВопрос только в нагрузке на сервер, которая вам как клиенту не видна.
Если это история про «часть контента я отрисую html страницей, а динамические данные я подтяну запросом» — так это и так можно делать, в чем проблема? Каких технологий или навыков вам сейчас не хватает чтоб это сделать?
Идея имеет право на жизнь, но для чеоо-то живого без сервера не обойтись: вот Хабр взять: сервер должен будет отрендерить новую страницу поста на каждый комментарий.
сервер должен будет отрендерить новую страницу поста на каждый комментарий.Почему не отдавать их JSON'ом через API? Или даже просто дописывать их в JSON-файл (клиент разницы с реальным API и не заметит). Если не гнаться за 100% валидным JSON, то можно написать туда массив без закрывающей квадратной скобки, и дописывать данные простым file append без перезаписи.
Narod не поддерживал никакого серверного кода, а писать все одинаковые элементы руками не хотелось.
Написал код сайна на PHP, развернул его локально. При изменениях скачивал все страницы wget'ом (кажется) и в статическом виде выкладывал на narod.
Такие жаркие дебаты разгорелись в комментариях всего лишь по одному вопросу: "Что это такое JAMStack?", по-этому оставлю ссылку на главный двигатель JAMStack на сегодняшний день с ответами на этот и схожие вопросы — https://www.netlify.com/
Так же владельцы соорудили справочник всех генераторов — https://jamstack.org/generators/
В блогах часто меняется. ) Вот Хабр — блог-платформа по сути ))
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.
Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
Нет серверным веб-приложениям