Pull to refresh

Comments 187

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Если информация не слишком часто обновляется, то можно просто дописывать её в файлы с данными, которые потом подгрузит JS на стороне клиента.

Для примера далеко ходить не надо. Посмотрите на Smashing Magazine. Они активно создают контент и у них JAMstack.


У них лежит около 4к md файлов и из них генерируются страницы.

А где можно почитать про их движок и пайплайн?

А чем это отличается от кеширования отрендереного HTML из «вариант №2»?
UFO just landed and posted this here
Это все здорово, только при чем тут веб-приложения? Лендинги, блоги с натяжкой и их родичи типа новостных порталов без поддержки комментариев, допустим. А веб-приложения тут коим боком? Какой-нибудь твиттер или телеграм, или, не знаю, биржа, например? Это вот веб-приложения.

А сайты, динамическая версия которых может быть просто запечена в статическую, к приложениям не имеют никакого отношения, имхо.
UFO just landed and posted this here

Вот именно. Статья как навязчивая реклама. Для приложений, где на странице много что меняется, совершенно не подходящее решение. Как пример — много где рекламные блоки меняют содержимое неоднократно, их что, каждый раз перегонять туда сюда…

Реклама как раз отлично меняется js-ом на статических страницах уже лет двадцать

Хорошую производительность на «хостинге» за 1 доллар вы не получите, поэтому это не преимущество перед кешем
А я не понял. Вот, допустим, у нас есть интернет магазин. Есть страница со списком товаров, для каждой единицы товара отображается доступность товара на складе. То есть у нас есть статический шаблон страницы, и есть волатильная информация, которая натягивается поверх шаблона. Натягивание информации на шаблон можно организовать на сервере — серверный рендеринг, или на клиенте. По такому принципу работают, как мне кажется, 95% сайтов. Объясните, пожалуйста, как я могу во время билда чего бы то ни было встроить информацию в страницу, если информация сама по себе не статична (а сайтов с принципиально статическим контентом, я даже себе представить не могу в 2021м году).
Сейчас у меня открыто в браузере: gmail, habr, linux org, jira, fisheye, youtube, confluence и reverso context. Для какого из этих рерурсов актуальна рекламируемая новаторская технология?
UFO just landed and posted this here
>Билдаем как статику без реальных цифр (т.е. без цена/количество товара). Раскладываем на CDN. Во время загрузки магазина, делаем запрос на API за данными, обновляем цифры.

А чем это отличается от сайта основанного на angular или react? Ну это же, блин, дословно, то же самое.
Я так понимаю, что автор предлагает примерно следующее:
У нас магазин, пусть будет 1000 товаров.
Значит мы генерируем 1000 отдельных статических страниц, по одной для каждого товара, с той информацией, которая практически не меняется или меняется редко — фото, описание, сопутствующие товары. После загрузки такой страницы через JS подтягивается оперативная информация — остатки по складу, цены, скидки и т.д.
То есть получаем смещение в сторону кэшированного SSR, по сравнению с полным CSR в Angular/React/Vue.
UFO just landed and posted this here
Я может что-то не понимаю, но можно же создавать файловый кэш, ложить его на диск, а веб-сервером дёргать файл и возвращать его, то есть готовую страницу, а если страницы в папке с файлами нет, то идём обычным путём…

На примере с магазином всё отлично будет работать… Сервер должен возвращать страницу без цены и наличия, а браузер уже дёргает эту инфу асинхронно…

При изменении товара не нужно перезапускать ребилд проекта, просто при сохранении удаляем файл с кэшем и всё, можно даже удалить файл и в фоне запустить сразу создание файла

У меня такое ощущение, что это просто новый вид кэша =)
Такое чувство, что автор инновациооного подхода борется с собсвенным невежеством, а не реальными проблемами.

>Разница в том, что в случае с SPA флоу выглядит так:

Да почему это вдруг? Никто же не запрещает встроить скрипты прям в страницу, и у вас не будет этапа загрузки js. Почему пользователь видит «белую страницу»? Разве SPA приложения определяют такое поведение? Да ничего же подобного, отдавайте страницу с внятным содержимым, изменяйте её по мере поступления данных.

>Здесь идея в том, что мы сразу отдаем Index.html с контентом

А как эта идея противоречит SPA дизайну приложения? Если есть возможность отдать страницу сразу с контентом, то я её отдам сразу с контентом, контент будет встроен в HTML. Далее мои скрипты обращаются к API, получают JSON и изменяют\дополняют контент если требуется.
Что нового то предлагается, я в толк не возьму.
UFO just landed and posted this here
>Поздравляю, вы убили кэширование скриптов
я ничего не убивал. Это ваша изначальная претензия к SPA, дескать, вот такой вот флоу и он вам не нравится. Мой ответ — не нравится вам этап загрузки скриптов, не загружайте. Вариантов всего два — загружать скрипты асинхронно или встроить их непосредственно в страницу. Оба этих варианты доступны без изобреиения новых сущностей.

>SSR появился сильно позже и как раз пытается решить те проблемы о которых я говорил.
Вы говорите о проблемах, которые сами же и выдумали, а теперь мужественно боретесь. На какой бы техлогии не был основан ваш сайт, все равно вы должны загрузить HTML самым первым этапом. Почему при использовании ангуляра этот инициализирующий HTML обязан быть белым квадратом — загадка сия есть, это вы просто выдумали.

>JAM стек предлагает отказаться от этого в пользу генерации контента разово, во вримя билда.
Я выше задал вопрос, на который мы сейчас и пытаемсёя получить ответ. Повторю его, каким образом я могу построить интернет магазин, если весь контент обязан быть известен на момент билда.

>Естественно это возможно далеко не всегда и не всегда имеет смысл.
Это никогда не имеет смыла. Так вообще работает весь интернет — контент не известен заранее. У сайтов есть админка, как правило. Персонал заказчика вносит изменения, получает их отражение на сайте. Пользователи работая с сайтом непрерывно изменяют данные, изменения непрерывно влияют на содержимое страницы. CMS на которых работает подавляющее большинство сайтов вообще нельзя постоить на статической основе, даже если страницы выглядят статичными. Я вам дал пример десятка сайтов с которыми работаю, дайте контрпример, покажите сайт, который может быть построен с использованием вашего чего-то там

>Это называется SSR.
Это любое занятие — выдумывать аббревиатуры.

> Вопрос терминологии и реализации.
Именно терминологии, а не реализации. Нет серверным приложениям, вроде так заявлялось? Оказывается, таки да, но давайте это называть немножечко по-другому, мы хотим написать десяток статей на эту тему и провести еще немножечко вебинаров.
UFO just landed and posted this here
>Вы предложили встроиться что бы уменьшить время ожидания. Я объяснил почему это проблема.
Нет. Я сказал, что есть два варианта — встраивать скрипты или не встраивать. У вас варианта тоже два, и оба вам не нравятся. Вам не нравится флоу СПА приложения, потому что загружаются скрипты, и одновременно не нравится встраивание скриптов. Третьего варианта вы не дали. Так дайте. Ответ «надо чего-то там встраивать на этапе билда» не отвечает на вопрос встраивания или загрузки скриптов. Если же загрузка скриптов никак не относится к теме беседы, то нафига вы это приводите в качестве недостатка SPA.

>Вам уже ответили выше. Генерим статичные страницы для товаров, данные (цена/кол-во) подтягиваем асинхронно с клиента.
Да что это за бред в конце концов? Все данные о товаре диначеские. Приведите пример нединамических данных для товара. Если говорите про изображение, то оно в страницу не встраивается, встраивается ссылка. А ссылка вполне себе вещь динамическая. Страница со списком товаров тоже динамическая по природе своей.

>Это не правда. Сайты визитки, редко обвновляемые блоги, сайты с инструкциями и просто любым статичным контентом подходят.
Ну то есть, имеются никие крохи из всего айсберга, называемого веб. Эти проценты страничек Васи Пупкина с единицами посещений в день не представляются проблемой для серверной производительности. Делаются они на CMS и прекрасно кешируются. Проблемы которую решает статья «Нет чему-то там» не существует. Спасибо, я понял.

Да что это за бред в конце концов? Все данные о товаре диначеские. Приведите пример нединамических данных для товара. Если говорите про изображение, то оно в страницу не встраивается, встраивается ссылка. А ссылка вполне себе вещь динамическая.

И насколько это всё динамическое? Сколько раз в минуту может меняться описание одного товара? А в час? Ну хотя бы оно меняется каждый день? Как правило нет. В большинстве случаев товар описывается один раз и к нему прикрепляется одна или несколько фотографий. После этого такие данные могут оставаться неизменными до исчезновения товара с продажи.
Да, они размещаются в БД и, формально, остаются динамическими. Но по факту они практически статические и на их основе можно периодически (или по факту изменения данных) генерировать новые статические страницы, на которых через JS будут заполняться динамические данные.
Сам факт того, что данные размещены в БД делает их строго динамическими. Сколько бы раз в минуту/час/год данные не обновлялись, с точки зрения сайта они обновляются в непредсказуемый момент времени. Вполне допускаю, что теоретически может существовать магазин, в котором цены указанные на сайте и сохраненные в БД могут не совпадать, список товаров может содержать позиции отсутствующие на складе, а одну единицу товара можно продать двум разным покупателям. Я бы хотел посмотреть как сайтостроитель будет объяснять такое поведение владельцу бизнеса! Это я молчу про то, что всегда есть данные рассчитываемые на лету — скидки, акции, всякая шняга из кукисов, есть корзина в которой данные хранятся временно, но тем не менее влияют на список товаров, есть стоимость доставки рассчитываемая на основе размера заказа, и так далее. И вот мы перешагнули в 2021й год, и тут у нас свежая мысль — а давайте прикешируем базку на час! Ну чтобы сэкономить процессорное время. Это пусть где-то в другом мире изобретают ин-мемори хранилища, занимаются всяки нормализациями, оптимизациями, индексы какие-то хитрые изобретают, шардируют чота там, все ради одного — ускорить доступ к данным. А мы пойдем другим путем! Мы вообще откажемся от обмена данными. Как вам мысль? Нет данных, нет проблем. Главное такты ЦПУ сэкономили, одни выгоды для бизнеса.

Вам это шизофренией не кажется? Мне кажется.
Так никто и не предлагает абсолютно все данные делать статическими. Но если данные меняются раз в пятилетку и не требуют особой оперативности, то что мешает сгенерировать статические страницы именно с этими данными, а остальные данные подтягивать динамически?
Насколько часто меняется именно описание товара? И насколько страшно, что корректировка описания (скорее всего из-за ошибки в нём), будет отображаться на сайте не сию же секунду, а, например, на следующие сутки?
Чем плохо, если в блоге при создании/изменении статьи будет генерироваться статическая страница, а комментарии к неё будут грузиться динамически?
Зачем генерировать статические страницы?
У вас есть данные, вы переживаете, что они медленно выгружаются, потому хотите генерить статику, но это не логично, вы по сути кешируете HTML, в то время, как можно закешировать данные о заказе, а то как он будет отображен, уже дело 10-е и не такое уж и долгое, особенно при серверном рендеринге, у вас же не хайлоады как у яндекса на поиске.

Итого, товар в кеше, сбрасываемый\обновляемый, если данные товара изменились, а рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко, скорость работы отличная, для 95% сайтов будет работать оптимально
рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко

Т.е. вы предлагаете всю (ОК, почти всю) БД держать в кеше?
Необязательно хранить структуру данных, что в БД в кеше, можно хранить в кеше подготовленные, данные, т.е презентованные, под нужную структуру, выборка из связанных таблиц и тд.

Данные в любом случае будет занимать меньше места, чем хранение HTML. Тем более, можно делать хранение, только основных данных, выборка которых занимает основную часть времени.

Вариантов работы с кешом масса, можно всегда прогревать кеш заранее, а можно делать это только при первом обращении, или только определенных записей, решение индивидуально под проект и проблемы которые возникают с производительностью

Опять же, кеш не панацея, если что-то тупит, надо чинить там, а генерировать готовый шаблон на этапе сборки, как описано в статье это самое последнее, что можно придумать
Т.е. вы предлагаете всю (ОК, почти всю) БД держать в кеше?

Так тут предлагают ту же самую БД держать в кеше, только не в виде данных, а в виде HTML с внедренными данными.
Именно, что если уж хранить все данные, на основе которых строится представление, то почему бы сразу не хранить представление? Если перевод данных в отображение — чистая функция, то нет смысла хранить отдельно функцию, а отдельно заранее аргументы её.
Это как раз таки не правильно, потому что если хранить уже конечный результат выходит огромное дублирование и оверхед.

Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Это как раз таки не правильно, потому что если хранить уже конечный результат выходит огромное дублирование и оверхед.
Дублирование чего? Если вы раз за разом отдаёте одно и то же, то ЭТО — дублирование и оверхед.
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Дублирование всей верстки, каждый раз делая ПРЕгенерацию всех страниц вы дублируете 1 шаблон на количество страниц с этими данными, пускай у вас магазин, в нем 10 000 товаров, у вас есть 1 шаблон, вы вместо того, чтобы в 1 шаблон врендеривать маленький хешик\json создаете 10 000 HTML страниц

Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?

Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx
Изменись у вас 1 атрибут, цена, артикул, да что угодно, вам нужно перерендерить 100500 шаблонов с этими данным. Это затратно по времени и в целом N+1 операция.

В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по факту
Изменись у вас 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 — А не на калькуляторе ли хостится сайт?
2 — А оптимальный ли код?
3 — А оптимальная ли работа с базой?
1. А не платить ли мне больше денег, вместо того, чтобы иметь другую архитектуру?
2. А не сделал ли я серверный рендеринг на каждый запрос, вместо того, чтобы кэшировать ответы в виде статики?
3. А не зря ли я хожу в базу, когда мог отдавать статику?
1. А не платить ли мне больше денег, вместо того, чтобы иметь другую архитектуру?

В данном случае, слово «архитектуру» надо взять в кавычки. И сложно представить экономию в серевере для такой задачи, видимо я не в том вебе работаю.

А не сделал ли я серверный рендеринг на каждый запрос, вместо того, чтобы кэшировать ответы в виде статики?

Тут я только развести руками могу, я уже не знаю

А не зря ли я хожу в базу, когда мог отдавать статику?


А зачем мне вообще база? странички HTML? можно же просто 1 PDF\Word файл скинуть и вуаля, прайс лист готов
А зачем мне вообще база? странички HTML? можно же просто 1 PDF\Word файл скинуть и вуаля, прайс лист готов
База — для отделения модели от представления. Генерация статики — для отделения генерации страниц от обработки запросов. А вы опять смешиваете в кучу отсутствие привычной вам архитектуры и отсутствие пользовательской функциональности.
Дублирование чего?

У всех защитников статических страничек сайт какой-то уж очень убогий получается. На словах то просто все — для каждой единицы товара генерируем страничку. Но это UX двадцатилетней давности. У вас нет всплывающих окон, тултипов, и вообще динамически подгружаемого контента. Я бы например хотел иметь список товаров с кратким описанием и возможность при нажатии мышкой получать более детальную информацию. Не перезагружая страницу как при царе Горохе, а используя современные удобные интерфейсы. Ну вот вам дублирование в чистом виде — вам одни и те же данные надо зашить в страницу дважды — к кратком виде в списке и подробном виде в скрытом диве.
У вас нет всплывающих окон, тултипов
Какая тут связь? Почему их не должно быть? У нас же не чистый HTML без скриптов.
Я бы например хотел иметь список товаров с кратким описанием и возможность при нажатии мышкой получать более детальную информацию. Не перезагружая страницу как при царе Горохе, а используя современные удобные интерфейсы. Ну вот вам дублирование в чистом виде — вам одни и те же данные надо зашить в страницу дважды — к кратком виде в списке и подробном виде в скрытом диве.
Вы пропускаете букву A в JAMstack? Никто не отбирает у вас AJAX и асинхронную подгрузку данных. Только серверный рендеринг в рантайме.

Слишком громкое название тогда "нет серверным приложениям" если сервер для АПИ всё равно нужен

Слишком громкое название тогда «нет серверным приложениям» если сервер для АПИ всё равно нужен
Просто вы «серверными» понимаете «хоть как-то использующие сервер», а автор мог иметь в виду, например, «использующие только сервер» или «исполняемые преимущественно на сервере».

Скорее всего автор имеет в виду "использующие серверный рендеринг html хотя бы раз в ответ на http запрос". Но из поста это не совсем очевидно, мягко говоря.

Ага. Ну синус и косинус тоже чистые функции, только почему-то никто давно не пользуется таблицами Брадиса. А вы предлагаете именно это, даже еще хуже, потому что по вашим словам получается, что ваша функция это функция одного аргумента. А это не так. Вернемся к нашему интернет-магазину. Допустим, у нас в каталоге 1000 единиц товара. Вы падженируете по десять элементов на страницу и того у нас сто страниц. Не много, можно заранее посчитать чистую функцию. Но откройте любой интернет-магазин. Увидите десятки фильтров. Примените фильтр к списку товаров и вот вы получаете другую страницу. Десять бинарных фильтров дадут вам 10! комбинаций. А если фильтры не бинарные, а скажем вам надо задать диапазон цен «от… до», то боюсь ваша чистая функция охренеет
Последние лет двадцать почти все, что происходит в клиент-серверных технологиях, это поиск лучшего способа отделения данных от представления. У вас как-то негласно предполагается, что для каждого товара вам нужна своя отдельная страница. Но чем товар А уникален по сравнению с Б, чтобы создавать собственное представление для него? Ничем. Вы предолгагаете хнанить нагенерированные странички, которые отличаются только текстом, при идентичнорй разметке. Зачем это надо вообще? Ни за чем. Достаточно один раз написать реакт компонент или серверный шаблон — не важно, который будет универсальным для любого товара, а конкретные цифры и текст — то что вы и так предлагаете грузить динамически — будет подставляться в шаблон по мере надобности.
Сам факт того, что данные размещены в БД делает их строго динамическими. Сколько бы раз в минуту/час/год данные не обновлялись, с точки зрения сайта они обновляются в непредсказуемый момент времени.
У вас сайт отдельно от CMS существует, что ли? Или пользователи руками в базе записи в таблицах правят? Почему вдруг этот момент непредсказуемый, если вы сами этот момент в своём приложении и обрабатываете, когда данные ы БД пишете? У вас же сайт, наверное, не простой интерфейс к чьей-то чужой БД?
У вас сайт отдельно от CMS существует, что ли?

Представьте себе! У меня есть сайт, у меня есть мобильное приложение, а еще у меня есть бухгалтерская программа, и весь этот зоопарк манипулирует данными в одной базе.
И что, нет единого места, через которое осуществляется запись в базу? Все прямо напрямую с СУБД общаются?
Что это за странное место такое, как оно архитектурно называется?

(микро)сервис, владеющий базой.

ээээ? Чтобы записать данные в БД нужен микросервис? А чтобы данные микросервису передать, нужен еще один микросервис? А я не понял. А зачем? Чем запрос в микросервис лучше запроса сразу в СУБД?

(Микро)сервис, который монополизирует работу с базой, в которую сейчас стучится несколько приложений, и хорошо если только одно на запись.


Чтобы трём приложениям сделать запросы в БД им всем нужно знать схему/ Иными словами, изменения в схеме нужно дублировать в коде всех приложений. Спрятав базу за сервисом (сделанным с нуля или преобразованным из одного из приложений) мы избавляемся от этого — минорные изменения схемы не повлияют на публичный API сервиса.

А вы можете дать ссылку на фундаментальный труд, где бы описывались подобные ухищрения? По мне идея выглядит полным абсурдом. Начиная с того, что проблема избыточности схемы данных для клиентов решается средствами самих СУБД. Бизнес логику положено хранить в хранимых процедурах, для того они и придуманы. Зачем мне нужен еще какой-то микро(!!) сервис поверх этого? Чтобы нивелировать мегатонну проверенных временем надежных промышленных решений — всякие пуллы соединений, тысячи оптимизаций, которые люди последние 60 лет внедряли, к черту вообще всю транзакционность похерить (или объясните как вы собираетесь обеспечивать транзакционную модель через HTTP). Камрад, ну это каким-то бредом выглядит

Если вашем мире серверные приложения в талицы не ходят и вообще только с хранимками общаются, то сложно вам будет объяснить проблемы, когда не одно, а несколько приложений ходят в базу и выполняют там напрямую UPDATE запросы. Хотя обвешаться хранимками, запретив прямой доступ к таблицам всем, и выставить микросервис — решения для одной и той же проблемы, по сути. Просто разные решения. Одним проектам подходит одни, другим — другие. В том числе и смотря какие люди работают на проекте. Я вот уйду с любого проекта как только там решат ключевую логику переносить в хранимки.


P.S. Транзакционность по http нормально делать: один запрос — одна транзакция. Как каждый вызов хранимки в транзакцию обернуть. Да и не говорил я про http.


P.P.S. Микро я везде в скобках ставил, чтобы подчеркнуть что оно не принципиально, а вы с ним так...

ээээ? Чтобы записать данные в БД нужен микросервис? А чтобы данные микросервису передать, нужен еще один микросервис? А я не понял. А зачем? Чем запрос в микросервис лучше запроса сразу в СУБД?


Микросервис просто дублирующий запись в БД — нет, не нужен.

А вот если он попутно проверяет права доступа пользователя, защищает БД от атак из прямого подключения к интернету, преобразует данные в различные форматы и пр. и т.п. — то да, польза от микросервиса есть.

Вот у меня есть корпоративная система написанная на JAVA EE, развернутая на WebLogic и коннектящаяся к Oracle. Теперь я хочу сделать сайт, который будет использовать ту же базу данных и выбираю технологию. Мне рекламируют некий JAM, который якобы не нуждается в сервере. Для чего я должен сделать с нуля (как было озвучено) некий сервис (очевидно каким-то образом безсерверный), который будет проксировать все запросы к ораклу и, очевидно, балансировщик нагрузки для него. В какое место я должен этот сервис засунуть не понятно, но да бог с ним, допусим засунул. А сервис мне нужен, чтобы инвалидировать кеш предварительно нагенерированных страничек, исходя из предположения, что будучи единственной точкой соединения приложений и СУБД сервис знает о том, какие данные изменились. Откуда это явствует? Ну правда, откуда этот сервис может знать, какие именно данные изменились в БД? Не может он этого знать. Следовательно, мне предлагают инвалидировать весь кеш предварительно настроганных страничек по любому событию изменения данных, даже если реальных изменений не случилось. А еще сервис нужен потому, что мне зачем-то надо заменять запросы типа «Select id, name from goodies» на «service.ru/goodies/all?fields=id,name». И вот этот набор абсурда выдается под флагом некой оптимизации.
Вот у меня есть корпоративная система написанная на JAVA EE, развернутая на WebLogic и коннектящаяся к Oracle. Теперь я хочу сделать сайт, который будет использовать ту же базу данных и выбираю технологию. Мне рекламируют некий JAM


Вы выбрали заведомо неподходящие начальные условия.
Откуда это явствует? Ну правда, откуда этот сервис может знать, какие именно данные изменились в БД?
Ну, если у вас всё на хранимках и триггерах, то запросто оно по триггеру на апдейт интересующих полей будет проставлять соответствующие флаги. Опять же, версионность записей у вас в БД не ведётся? Для тех же оптимистичных апдейтов? Флаг dirty/synced или таймстемп последнего изменения нигде не проставляется?
P.S. А в вашей архитектуре с n приложений, пишущих в общую базу — в каждом свой балансировщик, проверка прав, етц?
Товар А закончился, казалось небольшое дело, перегенерировали страницу.
Но этот товар А был в рекомендуемых «Так же люди смотрят» еще на 100-1000000 страниц товаров, их тоже перегенерировать? Или продолжать продавать то чего нету в наличии? Бизнесу это понравится, надо включить в презентацию Jamstack=)
Или это была динамическая информация? Итак, у нас цена, доступность, рекомендации, стоимость доставки, коментарии, пользовательский рейтинг, все тянется с сервера. Ради чего «предгенерация» ради названия товара и цвета шапки? Да, много сэкономили
А купить товар тоже можно без сервера?

-Никаких серверов!
-А как же цена товара, доступность, оценки?
-Ну это с сервера
-Но никаких сервров?
-Никаких серверов!
-А если сервер упадет?
-Ну бэкграунд увидите!

-Сирота?
-Сирота((
-Мама папа есть?
-Мама папа есть)))
Ради чего «предгенерация» ради названия товара и цвета шапки?
Ради название, описания, артикула, характеристик, хлебных крошек, меню, хедера, футера, разметки под эти и остальные блоки, карты магазинов, ссылок на скрипты и стили, аналитики и т.д…
Комментарии и отзывы, кстати, всё равно, обычно, предмодерируются, а цены меняются не руками в базе, а через CMS, которая вполне может запускать перегенерацию страницы. (А если прямо хочется руками в базе править, то можно повесить триггеры, помечающие данные «грязными»).
Если же вы про отдельные цены с персональными скидками, то такие чаще показываются уже в корзине. Которая рисуется джаваскриптом поверх готовой страницы.
Да, серверный код останется, но только там, где он нужен, а не на каждой странице, перерисовывая с нуля всю разметку на каждый запрос.
Это называется палить из пушки по воробьям, для таких вещей существует кеширование, как данных, так и определенных темплейтов, шапка сайта? ок, ее закешить не вопрос, это данные которые меняются раз в тысячелетие, а каждый раз генерить полную HTML версию под каждый товар, это тоже самое, что для каждой рисинки делать отдельную упаковку

Механизм рендеринга 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 тыс страниц, если достаточно хранить шаблон?
Абстрактно ваш шабло 1 КБ, значит вы на ровном месте сделали 3000 КБ только за счет их дублирования. И спрашивается вопрос — зачем?
Затем, что все эти пре-рендеренные запросы всё равно будут занимать места меньше, чем один только рантайм редиса. И меньше, чем одна HD-фотография в карточке товара.
Миллисекунды занимает рендаринг шаблона в браузере
Уже и в браузере, а не на сервере? И на телефонах? А то, что браузеры файлы тоже в дисковый кэш кладут — вы в курсе?
Только вот это лишние действие
Лишнее действие CMS? Ну, пометила бы она то же самое в базе, какая разница-то?
Вот послушав такие разговоры, я не удивлен, что большинство ресурсов, особенно на CMS тупят как адовый ад
Потому что на каждое действие ре-рендеринг делают? Давайте без переходов на личности, хорошо?
И меньше, чем одна HD-фотография в карточке товара.

Ну да, ну да…
А ничего, что картинка в данных это только ссылка на картинку? а картинки, как раз относятся к статике и кешируются веб-сервером (Nginx) так что этот пример в корни неправильный.
Уже и в браузере, а не на сервере? И на телефонах? А то, что браузеры файлы тоже в дисковый кэш кладут — вы в курсе?

Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.
Лишнее действие CMS? Ну, пометила бы она то же самое в базе, какая разница-то?

Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.
Потому что на каждое действие ре-рендеринг делают? Давайте без переходов на личности, хорошо?

Кстати тут не было перехода на личности, это скорее было сожаление по факту, т.к. часто сталкиваюсь с проблемами на сайтах, написанных с использованием CMS и возможно каких-то велосипедов. Так что тут извинения, если не так понято.

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

О кстати, еще в копилку перерендеринга — фронтещик или кто-то решил шаблон поменять, о нет, нам надо сделать перегенерацию всех товаров, потому что в блоке цены добавился новый CSS класс…
А ничего, что картинка в данных это только ссылка на картинку?
И что? Вы же про место на диске говорили? Или к чему был этот пассаж про «размер сайта»?
Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.
Что? Вы уже совсем ёрничаете. Речь шла о серверном рендеринге, а вы, почему-то, вдруг про генерацию в браузере начали писать. Теперь ещё и вот это…
Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.
Вы предлагаете данные и метаданные в разных местах хранить, или что? Чем ваши хуки на обновление кэша отличаются от хуков на удаление файла?
Нет, потому что изобретаются неправильные решения, которые выдаются за архитектуру, хотя это костыли и не желание разбираться в конечной проблеме, когда она есть.
Решения давно изобретены, называются «файловый кэш», и он есть встроенный в куче движков.
обычно

чаще

яснопонятно. Бизнес любит когда программисты делают не то что хочет этот самый бизнес, а то что «чаще» и «обычно».
директор: Наши маркетологи тут прикинули, давайте выводить цены для пользователей с индивидуальными скидками на всех страницах
программист: Знаете, скидки чаще в корзинах
Да, серверный код останется, но только там, где он нужен

А бывает по другому? но мы все равно назовем это безсервеный рендеринг? Потому что сервер все же у нас есть? логика то в чем?
сервер есть? есть, без него работать что-то будет? нет
как там кэш осуществляется, предварительной генерацией страниц в html файлики или по запросу байтиками в редисе, какая разница, это кэш называется, это не какая-то революционная технология и он от сервера не избавит. Если комуто хочется кэшировать в файлах, то ктож запретит.

допустим сервер на golang, в качестве шаблонного движка используется quicktemplate, он все шаблоны в бинарник загоняет.
Так вот, с какой стати прочитать страницы index.html и home.html с диска и отдать их будет быстрей чем сделать конкатенацию строк
header + indexcontent + footer, все уже в бинаре зашито, а за контентом в базу и так и так идти.

а через CMS, которая вполне может запускать перегенерацию страницы

поменяли цену на странице А, запустили перегерацию тысячи связанных страниц, потом поменяли на странице Б и запустили снова перегенерацию тысячи страниц, 900 из которых совпадают с первыми. А не эффективный ли вы менеджер?

Итог: У нас есть сервер приложений, у нас есть кэш. И мы почему-то называем это «нет серверам». без которых на самом деле ничего работать не будет.
яснопонятно. Бизнес любит когда программисты делают не то что хочет этот самый бизнес, а то что «чаще» и «обычно».
Ну, если бизнес требует править базу прямо руками, то бог им судья.
директор: Наши маркетологи тут прикинули, давайте выводить цены для пользователей с индивидуальными скидками на всех страницах
программист: Знаете, скидки чаще в корзинах
Оу, вы так пишете, будто это нереализуемо. Собственно, точно так же реализуемо на клиенте, в рантайме. Просто цены будут, например, подсчитываться JS'ом уже после загрузки разметки страницы. Причём, пользователь может об этом и не узнать.
А бывает по другому? но мы все равно назовем это безсервеный рендеринг? Потому что сервер все же у нас есть? логика то в чем?
Потому что РЕНДЕРИНГ будет делать НЕ СЕРВЕР. Никто же не говорил «безсерверный сайт»?
как там кэш осуществляется, предварительной генерацией страниц в html файлики или по запросу байтиками в редисе, какая разница
Разница в том, что генерация может осуществляться не кодом сайта вообще, а кодом CMS/деплой-скрипта. Ну вот не будет в серверном коде сайта кода, генерирующего HTML-разметку.
допустим сервер на golang, в качестве шаблонного движка используется quicktemplate, он все шаблоны в бинарник загоняет.
Так вот, с какой стати прочитать страницы index.html и home.html с диска и отдать их будет быстрей чем сделать конкатенацию строк
header + indexcontent + footer, все уже в бинаре зашито, а за контентом в базу и так и так идти.
Разница в том, что ваш код будет ходить в базу даже за данными, которые заведомо не менялись, парсить их и трансформировать соответствующим образом в разметку. Или он у вас сырой ответ от БД прямо байт в байт отдаёт посреди HTML?
поменяли цену на странице А, запустили перегерацию тысячи связанных страниц, потом поменяли на странице Б и запустили снова перегенерацию тысячи страниц, 900 из которых совпадают с первыми. А не эффективный ли вы менеджер?
Зачем у вас одна и та же одна цена отображается на тысяче страниц?
Итог: У нас есть сервер приложений, у нас есть кэш. И мы почему-то называем это «нет серверам». без которых на самом деле ничего работать не будет.
Если уж мы генерируем страницы при обновлении данных в CMS, то и кода этого на сайте быть не будет. Он в CMS, а не на сайте. И в отдаче контента клиентам не участвует.
Ну, если бизнес требует править базу прямо руками, то бог им судья.

а как вобще связано
Бизнес:«Я хочу чтоб были скидки»
Программист:«Нет мы их делать не будем»
с каким-то прямым хождением в базу, почему вобще база вызывает такой страх, что она приплетается к месту и не к месту?

Зачем у вас одна и та же одна цена отображается на тысяче страниц?

1)баннер с «Люди смотревшие это, так же смотрят»
2)Тысячи страниц фильтра «ТВ с диагональю до 50» «ТВ с диагональю до 49»… а наш целевой 30 и везде попадет.
Если уж мы генерируем страницы при обновлении данных в CMS, то и кода этого на сайте быть не будет. Он в CMS, а не на сайте. И в отдаче контента клиентам не участвует.

Еще раз, что значит не участвует? Купить товар можно без сервера? Ради чего заниматься перегенерацией тысяч страниц, если от сервера не избавились?
Или он у вас сырой ответ от БД прямо байт в байт отдаёт посреди HTML?

что знач сырой прям в HTML, там вобще может быть не html, а предобработанные данные. И да, если разрешено из конкретно той колонки базы вставлять html, то может быть и он.
ты же сам выше написал «Да, серверный код останется, но только там, где он нужен, а не на каждой странице, перерисовывая с нуля всю разметку на каждый запрос.»
вот тут он и нужен.
Если с базы мы тянем хоть что-то, хоть крохотулечку данных, запрос почти моментальный, вытягиваем допустим цены. что мешает вытянуть еще и название и артикул и описание. Это не повлияет на время ответа, все в одной таблице. и мы уже вместо 10000 страниц, каждая из которых отличается только названием, имеем один шаблон.
Разница в том, что ваш код будет ходить в базу даже за данными, которые заведомо не менялись

я верю что есть такие сайты, только интернет магазины не имеют к ним отношения.

Пользователь купил последний экземпляр товара, нам после действий пользователя надо пересчитать все страницы на которых как-то фигурировал этот товар? А найти эти страницы это очень сложная задача. И таких пользователей десятки сотни и все они как-то влияют, изменили рейтинг явно, изменли рейтинг просто посетив страницу, купили что-то.

Товар сам по себе может пораждать тысячи страниц. Вот появился у нас «Товар А» а у нас уже есть 100500 товаров в этой категории, нам надо создать 100500 новых страниц «сравнение А и Б»? а потом еще 100500**2 «Сравнение А Б и В»?
а как вобще связано
Бизнес:«Я хочу чтоб были скидки»
Программист:«Нет мы их делать не будем»
с каким-то прямым хождением в базу, почему вобще база вызывает такой страх, что она приплетается к месту и не к месту?
Ну, вы же как-то из «чаще» и «обычно» вывели «невозможно».
(вообще — да, забыл, почему я именно к этой цитате этот ответ приписал).
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'ом соответствующей карточки.
Оставшиеся же 1-5% спокойно себе загружаются асинхронно AJAX'ом.

Так оно и щас так, без jamstack.
Как часто такое происходит для товара? Неужели хотя бы несколько раз в день?

А че это мы только 1 вариант изменений выдернули из контекста и говорим «а это не часто случается», а как на счет остальных вариантов, оставил комент/оценку, просто своим просмотром поднял автоматический рейтинг интересности?
Воу, а вы и страницы результатов поиска/фильтрации предполали статикой делать?

Я, нет конечно, а вот вы поначалу да, но после вопросов… «Ну это мы с апи дернем, а это динамически сгенерируем, но сервера нам конечно не нужны, да»

У вас какие-то странные интернет-магазины, в которых все данные всё время непрерывно меняются

Букинг считается за интернет магазин где все время меняются страницы? «этот номер сейчас смотрят 3 человека» «Этот номер только что забронировали».
На любом современно интернет магазине есть динамичсекие данные.
я говорю, что если сервер используется хоть для одного поля рейтнг/оценка/личная скидка/рекомендации, то нет никакого смысла рендерить 100500 страниц чтобы потом все равно с них дергать апи. Если хотим снять нагрузку с бэкэнда то используем кэш, хоть всю страницу хоть данные.

снизив TFFB в десятки раз

Ради десятков раз можно много че делать. ну например закэшировать реально тяжелый запрос, сам рендеринг не занимает ничего
Так оно и щас так, без jamstack.
У вас только 1% загружаемых данных не генерируются в момент запроса? Так поздравляю, у вас JAM.
А че это мы только 1 вариант изменений выдернули из контекста и говорим «а это не часто случается», а как на счет остальных вариантов, оставил комент/оценку, просто своим просмотром поднял автоматический рейтинг интересности?
Вотэбаутизм какой-то. А что это вы сами из моей «простыни» ответов только на несколько строк отвечаете, при том, что сами мне предъявляете, что я не на всё ответил?
Я, нет конечно, а вот вы поначалу да, но после вопросов… «Ну это мы с апи дернем, а это динамически сгенерируем, но сервера нам конечно не нужны, да»
Где это я говорил, что сервера не нужны? Зачем вы мне приписываете то, чего я не говорил?
Букинг считается за интернет магазин где все время меняются страницы? «этот номер сейчас смотрят 3 человека» «Этот номер только что забронировали».
Отличный пример! А теперь скажите — пришли ли эти данные в составе страницы, или загружены аяксом в виде JSON из API?
Подсказка

На любом современно интернет магазине есть динамичсекие данные.
Есть, но во всех местах, где эти данные действительно часто меняются — они подгружаются аяксом из API, а не рендерятся в разметку самой страницы.
сам рендеринг не занимает ничего
Такое ничего, что люди от него за кэширующими прокси и CDN прячутся.
Эти проценты страничек Васи Пупкина с единицами посещений в день не представляются проблемой для серверной производительности.


Так там потому и единицы посещений в день, что они не на JAM-е! А были бы на JAM-е, там бы отклик был на 2мс ниже и сайт бы смыло волной трафика. Или нет.
Я выше задал вопрос, на который мы сейчас и пытаемсёя получить ответ. Повторю его, каким образом я могу построить интернет магазин, если весь контент обязан быть известен на момент билда.

Если учет ведется не на сайте интернет-магазина, а в какой нибудь специализированной системе, например, 1С или т.п., то у вас присутствует регулярная подгрузка новых товаров.

В этот момент можно перебилдить статические страницы каталога товаров интернет-магазина.

Делал так в продакшене. Билд на офисном внутреннем сервере, после чего деплой на веб-сервер.

Для пользователя интернет-магазина — сплошное удобство:

Веб-сайт обновляется мгновенно.
Страницы загружаются мгновенно.
UFO just landed and posted this here
для решения пунктов 1 и 2 уже какое-то время в ходу PWA, которое позволяет хранить «приложение» или «каркас» (джсник короче) на диске у браузера через удобный и гибкий API: Caching API, CachedDB и, конечно, ServiceWorker.

Проблема медленного рендера давно решена кешированием. Да, не всегда спасает, но деплой 5 часовой 150тыс. страниц Вас тут тоже не сильно спасёт, если поменяв немного лейаут нужно будет их прегенерить заного.

Генерить темплейты в билде не актуально по одной простой причине — слишком быстро всё меняется, быстрые релизы — тоже для многих важны. С этим бегемотом это невозможно.

Блог или новостник — с ростом кол-ва страниц будет увеличиваться длительность билда, хорошо если пропорционально. Если паралелить — этож какой билд сервер нужен чтоб 20к страниц сгенерить.

А еще такой момент — автор, ты видел как выглядит перерисовка страницы, когда рендерится темплейт без данных, как потом весело всё скачет когда данные подставляются. Эта проблема имеет пути решения, но они не тривиальны.
И если в SPA приложении у тебя есть циклы жизни приложения и соответствующий API лдя работы с различными ивентами — то у тебя тут только статика, тонна проверок и спагетти код чтобы контролировать все состояния.

Для личного лендинга, который обновляется раз в три года — может остановится на любой генераторе статики, а еще лучше собрать ручками, потренироваться, так сказать.

Еще один коммент по поводу статика на запрос или статика при билде:
у тебя есть 20к страниц, деплой раз в неделю. Предположим 50% страниц на которые заходят 0-1 посетитель в месяц. Сколько времени, ресурсов и сколько ненужных данных будет сгенерировано за этот месяц? По этому — у тебя есть «генератор» ответа и кеширующий механизм, в котором, помимо того чтобы хранить тот же «сгенерированый контент» ты еще можешь управлять точечно «сроком годности» этого контента. Устарел — сгенерили заного, по запросу.
Такое впечатление, что кто-то не разобравшись в доках и напилив сервисы отвечающие по 10 секунд пытается придумать супер решение. Решение, ИМХО, очень нишевое.
А деплои… всё равно будут сложные, т.к. нужно версионирование и откат на предыдущие версии, так что еще и за дисковое пространство надо будет накинуть.

А API так вообще по-старинке придётся поддерживать.
А еще такой момент — автор, ты видел как выглядит перерисовка страницы, когда рендерится темплейт без данных, как потом весело всё скачет когда данные подставляются.
Если у вас часть данных не отдаётся дольше, чем все, включая рендеринг, то на время загрузки можно просто крутить спиннер и ничего не показывать.
И если в SPA приложении у тебя есть циклы жизни приложения и соответствующий API лдя работы с различными ивентами — то у тебя тут только статика, тонна проверок и спагетти код чтобы контролировать все состояния.
А почему, если не SPA, то сразу спагетти-код и вот это вот всё? Какая связь? Есть же даже и фреймворки готовые примерно к этому, типа React Static.
По этому — у тебя есть «генератор» ответа и кеширующий механизм, в котором, помимо того чтобы хранить тот же «сгенерированый контент» ты еще можешь управлять точечно «сроком годности» этого контента. Устарел — сгенерили заного, по запросу.
Ну, и отлично? Генерация по запросу готовых HTML-страниц, обновление кэша через удаление файла из файлового кэша. При этом, пока страницы не обновляются, всё будет происходить как описано у автора.
1) Ну сначала нам нужно загрузить основную разметку, скрипты и запустить их — чтобы подтянуть данные. Соответственно нужны какие-то «наполнители». Тот же крутящийся круг — круто, но когда данные подтягиваются с разных API и скорость их загрузки разная — тут или ждать пока мы получим всё, или смотреть на «прыгающую» разметку. Контролировать рендер — всё равно нужно скриптами. Так мы приходи к уже устоявшемуся SPA.

2) Реактивность, если это не SPA, обычно заканчивается кучей невнятного кода. Как и любые попытки посредственных разработчиков создать собственное решения с блэкджеком… ту не конкретно к автору или кому-то, просто так случается. Почти всегда.

3) Есть сомнения насчет «удалить файл из файлового кэша». А новый мы как создадим? А если я правильно понял автора — то нам нужно запустить билд. Билдить приложение, чтобы почистить кэш — это перебор. Если мы генерируем статику точечно… зачем переизобретать кэш (тот же Varnish), который будет работать медленнее (память быстрее FS). Опять же — как нужно автоматизировать весь процесс билда и деплоя, написать обвязку для очистки и новой генерации, сколько железных ресурсов на это нужно — даже думать не хочется.

П.С. Статика есть статика. Где-то — подходит, но в нашем динамичном мире — достаточно редко. Массово применять такой подход — скорее всего не получится, или будет представлять из себя кучу костылей. А для тех, кто боится серверов, деплоев и прочее — есть решения типа serverless, когда всё окружение работает «почти без участия разработчика», в том числе горизонтальное масштабирование. До поры, до времени, конечно :)
1) Ну сначала нам нужно загрузить основную разметку, скрипты и запустить их — чтобы подтянуть данные. Соответственно нужны какие-то «наполнители». Тот же крутящийся круг — круто, но когда данные подтягиваются с разных API и скорость их загрузки разная — тут или ждать пока мы получим всё
И в чём проблема-то? Серверную страницу вы столько же времени и ждали бы — пока все API ответят.
Контролировать рендер — всё равно нужно скриптами. Так мы приходи к уже устоявшемуся SPA.
Почему если скрипты, то сразу SPA-то?
2) Реактивность, если это не SPA, обычно заканчивается кучей невнятного кода. Как и любые попытки посредственных разработчиков создать собственное решения с блэкджеком… ту не конкретно к автору или кому-то, просто так случается. Почти всегда.
SPA — это всего лишь сайт с одной точкой входа. Никто не мешает вам тот же Реакт использовать хоть на тысяче страниц. Посмотрите, например, на React Static. Он специально для этого и написан.
Если мы генерируем статику точечно… зачем переизобретать кэш (тот же Varnish), который будет работать медленнее (память быстрее FS).
Только вот кэш NGINX, например — именно файловый. И в состоянии простоя не потребляет ни ЦП ни памяти, переживает перезагрузки и не требует никакого доп. ПО для отдачи его. А кэш в той же MediaWiki — файловый из коробки.
Опять же — как нужно автоматизировать весь процесс билда и деплоя, написать обвязку для очистки и новой генерации, сколько железных ресурсов на это нужно — даже думать не хочется.
Вы так пишете, как будто про прогрев кэша никто не слышал, и это автора поста его только что придумал, заодно изобретя огонь и колесо. Особенно интересно, что вы боитесь задачи очистки файлового кэша: на секундочку, заключается она в банальном очистки папки с ним.
А для тех, кто боится серверов, деплоев и прочее
Это вы же выше написали, что деплоя боитесь =)
UFO just landed and posted this here
А я не понял. Вот, допустим, у нас есть интернет магазин. Есть страница со списком товаров, для каждой единицы товара отображается доступность товара на складе. То есть у нас есть статический шаблон страницы, и есть волатильная информация, которая натягивается поверх шаблона. Натягивание информации на шаблон можно организовать на сервере — серверный рендеринг, или на клиенте. По такому принципу работают, как мне кажется, 95% сайтов. Объясните, пожалуйста, как я могу во время билда чего бы то ни было встроить информацию в страницу, если информация сама по себе не статична


Делал интернет-магазин на статике.
Все страницы с товаров регулярно обновлялись по мере прихода новых наименований товаров.

Остатки товаров отображались с помощью API. То есть при загрузке страницы с товаров в браузер пользователя кнопочка «Купить» или надпись «Нет в наличие» определялась автоматом, хотя всё прочее содержимое — статическое.

Корзина, разумеется, тоже динамически контент свой показывала пользователю. Так же — статическая страница корзины без контента. А сами наименование товаров, положенные пользователем в корзину, отображались динамически.
Я не настоящий сварщик — а вариант когда отдается разметка, параллельно в JSON или иным образом отдается закешированный контент, и на клиенте уже второе вставляется в первое, так не принято?
Опять же, если контент уже скачан, он возьмётся из локального кеша.
Т.е. вы изобрели велосипед кэширование отрендеренных страниц?
UFO just landed and posted this here
А зачем что-то генерировать на сервере или клиенте, если можно делать это во время билда?
Т.е. берем вариант №1, делим на компоненты, закладываем контент, например, в локальный json и… собираем статику. При необходимости что-то изменить или собрать приложение, просто вносим нужные изменения и пересобираем проект.
UFO just landed and posted this here

Допустим, изменилось описание одного статического элемента (товара), и мы условно "разворачиваем веб сервер заново" (пересобираем проект). Спасибо, но нет.

Зачем пересобирать проект чтбоы обновить одну страницу? Частичные билды, вот это вот всё…

Описание одного товара может отображаться на каждой странице сайта

Но зачем?.. Что это за товар такой, что его на каждой странице нужно показывать?..
Ну, и, кстати, иметь для каждого товара кроме полной карточки ещё и её мини-версию для подгрузки на другие страницы — тоже виданная практика.

Флагманская модель, баннер с которой бизнес хочет поместить на каждую страницу.

Такие баннеры, обычно, это или картинка (которая просто заменяется по ссылке), или фрейм/подгружаемый AJAX'ом сниппет.

Ну вот все страницы со ссылкой надо перегенерировать, да, когда картинку надо поменять?

Так зачем её перегенерировать-то, если она по ссылке? Кладём туда другую картинку, и всё.

закэшируется — не страшно?

Так с этим известно, как справляться.

Придумываем себе проблемы и героически их решаем? )

Так любая страница, файл или ответ API может закэшироваться, от проблемы контроля кэша нигде не деться, в любой работе с вебом.

Так один из способов борьбы с нежелательным кэшированием картинок как раз перегенерации ссылок на них. На фронтенде я бы сказал, что основной

Так один из способов борьбы с нежелательным кэшированием картинок как раз перегенерации ссылок на них. На фронтенде я бы сказал, что основной
Так ведь там, обычно, меняют незначимую часть ссылки, добавляя избыточный параметр в 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 оставьте

И как вы это предполагаете реализовывать? Делать PWA с Service worker'ом?
В RFC7234 такого значения для Expires не предусмотрено. Но, предположим, вы выставите дату на 100 лет вперёд — теперь у вас есть список имён, которые вы никогда не сможете дать новым файлам, потому что вместо них могут(!) у каких-то пользователей показаться старые. И этот список будет пополняться с каждым обновлением. В итоге от идеи давать просто осмысленные имена придётся либо отказываться, и дописывать-таки дату в имя, или, как минимум, хранить все старые версии файлов, чтобы случайно не дать новому имя старого.

Хранить список и при деплое инкрментит суффикс _N или типа того

Инкрементить для всех файлов? Чтобы они все каждый деплой перезагружались у каждого пользователя? Или-таки хранить историю версий всех файлов в системе?
Можно просто брать время изменения файла в виде числа — если файл реально менялся, то число будет другое, если нет — тоже

Тогда уж лучше хэш файла использовать.

Можно просто брать время изменения файла в виде числа — если файл реально менялся, то число будет другое, если нет — тоже
Это всё равно будет
и дописывать-таки дату в имя

То, что вы описываете — это SSG. JAMStack пребилдит в основном Markup и может делать пререндеринг страниц, но потом охотно использует API (который в свою очередь общается с базой или Headless CMS) и без труда рендерит на клиенте при помощи JavaScript (после регидрации обычно только так и рендерится). Собственно из подчеркнутых символов и формируется JAM. Кстати, вам до этого задали хороший вопрос, попробуйте добавить в свой пример с блогом комментарии пользователей.

UFO just landed and posted this here

SSG — это один из инструментов JAM. Мы же не называем колеса частным случаем машины. Если я для вашего примера возьму, скажем Hugo или Zola, то там не будет ни "J", ни "A". Странно называть такое решение JAM, не правда ли?)

Но ведь у вас всё равно в итоге получился не JAMstack. Вы всё ещё используете чисто второй подход скатываясь к первому, только рендер перенесли с on-prem на этап сборки. В итоге на выходе у вас только статическая разметка (пусть и сгенерированная). Это путь всевозможных статических генераторов и только часть JAMstack, даже не половина, а скорее треть.


Чтобы получился действительно настоящий JAMstack нужно скрестить все 3 варианта. Причём даже в статье расшифровка приведена JavaScript API Markup. Т.е. к вашему варианту нужно ещё добавить сервер с API (и вот оно расхождение в статье) и клиентский JavaScript код, тогда у вас будет действительно JAMstack.


Фактически сайты на React/Vue/etc, если используют API, гидрацию и будут собирать страницы в статику именно на этапе сборки — настоящий JAMstack.


Чтобы понять что такое JAMstack, оставлю ссылку на JAMstack.wtf. А вообще всё это довольно олдскульно, даже JAMstack существует далеко не 4 года и не 8.

UFO just landed and posted this here

Это правда. Просто получилось, что те кто понимают суть JAM хотя бы частично, горят что пример только часть JAM'а, а те кто не в теме получили либо не полное, либо ложное понимание. Автор оригинальной статьи тоже "молодец" с его "Нет" серверам, и в середине "Да" серверам.

UFO just landed and posted this here
У JAMstack есть один минус, который проявляется не сразу, но потом начинает сильно раздражать. А именно: дико увеличивающееся время генерации целого сайта.
В итоге на статических сайтах с 1000+ страницами время билда может доходить до получаса. Потому что даже в случае изменении одной страницы новый билд запускается для всего сайта.

Например контент менеджеру надо было добавить пару новых блоков в блоге. Он идет в админку JAMstack CMS, делает правки и отправляет измененную статью на публикацию. Теперь, для того, чтобы убедиться, что изменения дошли до продакшена, он должен полчаса жить в режиме «не забудь проверить продакшен». Вроде, как можно поставить напоминалку и т.д., но по сути в эти полчаса ничем продуктивным заниматься невозможно. А если он что то пропустил, забыл или заметил опечатку? Снова билд на полчаса.
Если несколько менеджеров работают над разными статьями, то каждый будет запускать процесс деплоя для всего сайта.

Разные CMS предлагают различные варианты решения этой проблемы. Gatsby вот например предлагает Incremental Builds, которые те же полчаса могут превратить в 10 сек (согласно рекламе). Но эта опция доступна только на их платном Gatsby Cloud.

Статически сгенерированные сайты определенно несут преимущества для конечного пользователя. Но стоит помнить, что у всего есть своя цена.

На самом деле всё зависит от подхода, можно каждый раз генерировать полностью целый сайт, а можно перегенерировать только изменившиеся страницы (Incremental Build). Это конечно ещё и от инструментов зависит.


Вообще стоит сказать, что JAMstack может быть и без генераторов на самом деле. Если у вас собранная руками html страничка и есть как клиентский JavaScript, так и запросы к API — вы уже используете JAMstack. Даже если страница фактически будет тупо скелетоном это всё ещё JAMstack, хотя больше продвигается "прогрессивный" подход. Тут важно ещё не забывать про клиентскую сторону — мегабайты кода. Всё это всё ещё нужно оптимизировать.


Статически сгенерированные сайты определенно несут преимущества для конечного пользователя. Но стоит помнить, что у всего есть своя цена.

А вот это в рамочку. В зависимости от подхода к JAMstack вы будете платить временем и объёмом хранилища.

UFO just landed and posted this here

Вау, так это же практически описание opcache + memchaced!
Перезагружать статические страницы при переходе от одной к другой, где меняется только текст — долго, гораздо лучше использовать кеширование запросов (та же статья в html) + обновление содержимого. Этим вполне успешно занимается livewire или react и ему подобные.

Next.js что ли (олд скул + сервер рендер)? Дико извиняюсь если ляпнул.
Апи не занимается выдачей HTML. Оно выдает грубо говоря JSON с данными и передает его генератору HTML (вебапу)
Пользуетесь ли вы JAMstack?

Нет ибо LEAMP + Bitrix наше всё :) !

В последние годы из-за стремления переложить вычисления с сервера на клиент браузеры стали отъедать неимоверное количество ресурсов на многих сайтах. Мне кажется нужен все же какой-то баланс между сервером и клиентом, при этом сервер должен производить самые затратные операции, а клиент более легкие.
необходимые для приведения приложения в работоспособное состояние, с сервера в браузер.

Сказано так как будто это что то хорошее
что ж вы все колесо то изобрести пытаетесь… Статичные сайты без изменяющейся регулярно инфы итак никаких проблем с скоростью отдачи не испытывают. Но подавляющее большинство сайтов а) регулярно меняют отображаемые данные; б) хранят где-то эти данные. Если вы не предлагаете каждый раз ребилд дергать как условный Вася в админке поменял одну цифру, то вам все равно придется за этими данными куда-то лезть. Да можно прикрутить какой-нить graphql на фронт и кому-то такой вариант пойдет. Но попытка запихнуть все бизнес логику на фронт для относительно сложного проекта с вероятностью 100% породит такого монстра, что расширять и поддерживать его будет редкостным и чрезвычайно дорогим гемороем.
Ну допустим у нас блог, наподобие хабра на JAM. А комментарии в него как завернуть? А без комментариев все эти блоги и статьи пшик.
Комментарии будут, например, в отдельном файле (HTML или JSON), который можно периодически дописывать.
UFO just landed and posted this here
Сервис, который за букву A отвечает в JAM.
Обычно монолитные серверные приложения превращаются в монстров. А разбиение монолитного приложения на микросервисы ...
— мир окрашен в два цвета? Про SOA в 2021 году никто не слышал?
Для сайта-визитки, возможно этого и достаточно, но когда разговор идет о «настоящем» сайте с кучей логики и состояний, этот подход нежизнеспособный.

Тем более, перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернета или компьютера пользователей.
перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернета
Во-первых, по сравнению с SPA, тут нагрузка перекладывается на билд. Во-вторых, не наоборот ли, в случае слабого интернета как раз меньше запросов придётся делать?
Запросов то может и меньше, а вот объем данных больше, тут же подразумевается уже работа с отренндренными шаблонами, значит мы передаем их, в то время, когда в классическом SPA мы можем использовать либо клиенский либо серверный рендеринг.
Причем в случае клиентского, с бекенда придут только данные, и скорее всего, их трафику явно будет меньше, чем HTML разметка.

Ну и опять же, подход описанный в статье, это чисто для статических сайтов.
Причем в случае клиентского, с бекенда придут только данные, и скорее всего, их трафику явно будет меньше, чем HTML разметка.
Зато придёт куча кода фреймвока-шаблонизатора размером в несколько мегабайт, чтобы в рантайме собирать страницу.

JAMstack не противоречит SPA, а даже наоборот. Главный манифест JAM — JavaScript API Markup, а это всё есть почти в любом SPA (есть SPA не использующие API серверов).

стесняюсь спросить, а как получить данные из api или бд, во время генерации, если нет серверного приложения с логикой и данными?.. мне кажется описан подход SPA(singe page application), где приложение можно самим с сервера отдавать как статику или в cdn положить.

стесняюсь спросить, а как получить данные из api или бд, во время генерации, если нет серверного приложения с логикой и данными?..
Так приложение у вас будет, но оно будет генерировать статические страницы при билде, а не обрабатывать запросы клиентов.
мне кажется описан подход SPA(singe page application), где приложение можно самим с сервера отдавать как статику или в cdn положить.
Reply
В SPA страница одна (Single page), т.е., один HTML-файл, а вся разметка генерируется или подменяется динамически на клиенте. Тут же предлагают всю разметку генерировать заранее. Соответсственно, страниц может быть много.

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 то это выглядит слабовато для подачи сабжа как новой парадигмы. К тому же сам факт того что технология практически не дожила до наших дней говорит о многом.
UFO just landed and posted this here

Автор сам запутался во всех "новых" словах которые он узнал за последние пару лет.


  1. В начале он говорит нет серверам и на середине статьи говорит, а вот JAMstack (у которого на минуточку API это сервера). Т.е. он сам себе противоречит.
  2. 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, и все собирается на стороне клиента "без сервера", как бы употребил автор статьи. Но подход оказался совсем не удобным)

А в чём неудобность?

XSLT, как и XML в целом — достаточно громоздкая штуковина. Глядя в документацию, конечно, разобраться с XSLT можно, но оно как-то быстро выветривается из головы.

Тезисов тупее чем в этой статье ещё поискать если честно

Проблема такой технологии в том, что она решает частный случай. И если будет хотя бы 1% реально динамической информации, которую нужно отдавать в реальном времени, то придется параллельно с придуманной технологией использовать классические методы. Зоопарк получится. Т.е идея имеет смысл, но выгода от ее использования сомнительная. Недостаток я озвучил. Но фишка даже не в этом, реально проблемы в текущих технологиях по сути нет. Вот я хожу по сайтам. Скорость меня устаивает. Ну, то есть, если делать сайты/приложения нормально, оптимизировать запросы, кешировать и подобные фишки, все будет ок и без данного велосипеда
Проблема такой технологии в том, что она решает частный случай. И если будет хотя бы 1% реально динамической информации, которую нужно отдавать в реальном времени, то придется параллельно с придуманной технологией использовать классические методы.
Там есть запросы к API (буква А в JAM). Или вы в реальном времени страницу перезагружать с сервера предлагаете?
Вот я хожу по сайтам. Скорость меня устаивает. Ну, то есть, если делать сайты/приложения нормально, оптимизировать запросы, кешировать и подобные фишки, все будет ок и без данного велосипеда
Вопрос только в нагрузке на сервер, которая вам как клиенту не видна.
Где же вы берете такие проблемы, с которыми потом успешно боретесь? Когда вам приходилось последний раз разрабатывать сайт с статичными данными? И приходилось ли вообще? Мне — нет.

Если это история про «часть контента я отрисую html страницей, а динамические данные я подтяну запросом» — так это и так можно делать, в чем проблема? Каких технологий или навыков вам сейчас не хватает чтоб это сделать?

Какой из популярных фронтенд фреймворков позволяет генерировать сотни и тысячи статических страниц по роутингу а потом подгружать данные? Обычно они завязаны на один index.html на все страницы

Идея имеет право на жизнь, но для чеоо-то живого без сервера не обойтись: вот Хабр взять: сервер должен будет отрендерить новую страницу поста на каждый комментарий.

сервер должен будет отрендерить новую страницу поста на каждый комментарий.
Почему не отдавать их JSON'ом через API? Или даже просто дописывать их в JSON-файл (клиент разницы с реальным API и не заметит). Если не гнаться за 100% валидным JSON, то можно написать туда массив без закрывающей квадратной скобки, и дописывать данные простым file append без перезаписи.
зарегестрировался для того, что бы сказать — автор неадекватен в своих суждениях.
Делал в ~2009 году по похожему принципу battguard.narod.ru.
Narod не поддерживал никакого серверного кода, а писать все одинаковые элементы руками не хотелось.
Написал код сайна на PHP, развернул его локально. При изменениях скачивал все страницы wget'ом (кажется) и в статическом виде выкладывал на narod.

Такие жаркие дебаты разгорелись в комментариях всего лишь по одному вопросу: "Что это такое JAMStack?", по-этому оставлю ссылку на главный двигатель JAMStack на сегодняшний день с ответами на этот и схожие вопросы — https://www.netlify.com/
Так же владельцы соорудили справочник всех генераторов — https://jamstack.org/generators/

Нет серверным веб-приложениям? Такой громкий заголовок, а по факту этот подход годится лишь для всяких блогов, где информация меняется относительно редко. То есть область применимости крайне узкая.

В блогах часто меняется. ) Вот Хабр — блог-платформа по сути ))

Я имею в виду всё же более примитивные блоги. Там, где есть возможность хотя бы оценить пост, такой подход уже не годится.

Внешние сервисы можно прикрутить для оценок и комментариев )

Оценками и комментами дело может и не ограничиться. В любом случае если обвешаться внешними сервисами, то смысл во всей этой затее в итоге пропадёт, потому что это не гибко, и работает лишь на совсем типовых вещах. Но спорить не буду.
В данном случае это вовсе не попытка придумать новый подход к разработке сайтов. Технически, подходы те же что и раньше, может чуть в другой обертке для отвода глаз. Так что же это за волна статей про всякий «no code»?
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.

Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
Only those users with full accounts are able to leave comments. Log in, please.