Jamstack: сборка, CDN и вебхук

Jamstack — подход, при котором страницы собирают заранее и раздают через CDN, а динамику берут из API и внешних сервисов. Правку в CMS подхватывает вебхук.

Что такое Jamstack

Слово придумали в 2010-х: JavaScript, API и Markup (разметка). Популярным его сделал Матиас Биллманн, основатель компании Netlify, в докладе 2016 года. Сегодня на сайте Jamstack.org подход описан так: показ страницы отделён от данных и логики, а нужная логика и сторонние сервисы подключаются через API. Слово «Jamstack» в маркетинге стало менее модным, но идея осталась: её называют «составным» (composable) вебом.

На практике это значит три вещи, и вы уже знаете каждую:

1. Страницы собираются заранее (урок 5): на сервере лежат готовые HTML-файлы.
2. Раздаются через CDN (сеть серверов по миру: ближайшая копия отдаёт страницу быстро; подробно в части 9).
3. Динамика берётся извне: содержание у API headless CMS (урок 6), формы, поиск и оплата у сервисов или в коротких функциях.

Путь правки до посетителя

Самый важный механизм здесь, как правка в CMS попадает на живой сайт. Поэтому вебхук, сборка и откат стоит увидеть вживую. Нажмите «Опубликовать», пройдите по шагам и сломайте любой этап.

Модель с придуманными секундами. Отметьте этап, который «сломается», и пройдите путь правки по шагам.

1. Публикация в CMS сломать
   Редактор нажал «Опубликовать»: запись сохранена.
2. Вебхук сломать
   CMS отправила сборщику сообщение «содержание изменилось».
3. Сборка сломать
   Генератор берёт содержание у API и собирает все страницы заново.
4. Выкладка сломать
   Готовая папка загружается на хостинг и включается разом.
5. Раздача (CDN) сломать
   Копии страниц по всему миру обновляются, старый кэш сбрасывается.

Опубликовать Сначала Откатить на прошлую версию

Посетитель сейчас видит: v12: прежняя версия.

Страниц на сайте: 200

Сборка займёт около 25 с, весь путь от «Опубликовать» до посетителей около 42 с. Для небольшого сайта это почти мгновенно.

Текстовая альтернатива: путь правки состоит из пяти этапов: публикация, вебхук, сборка, выкладка, обновление копий в CDN. Если один из них ломается, посетитель продолжает видеть прежнюю версию, потому что новая включается целиком и только после успешной сборки. Откат это переключение на прошлую собранную версию. Время сборки растёт с числом страниц.

Что стоит заметить.

• Вебхук это «звонок»: CMS сама сообщает сборщику «содержание изменилось». Без него правку пришлось бы запускать вручную.
• Выкладка атомарная: новая версия включается целиком и только после успешной сборки. Поэтому упавшая сборка не ломает сайт: посетитель продолжает видеть прежнюю версию. Даже на живом сайте нет «наполовину обновлённого» состояния.
• Откат это переключение на прошлую собранную версию. Хостинги хранят их, и возврат занимает секунды. Потом вы спокойно исправляете запись и публикуете снова.
• Время растёт с размером сайта. На двухстах страницах сборка занимает меньше минуты, на десяти тысячах уже заметно. Предел предсборки: каждая правка пересобирает всё. Решения: быстрые генераторы, пересборка только изменённых страниц, и страницы, которые собираются по запросу и кэшируются (гибрид, который умеют современные фреймворки).

Проверьте себя: что увидит посетитель, если сборка упала?

Прежнюю версию. Новая версия включается только после успешной сборки и целиком, поэтому сайт остаётся на последней рабочей.

Чего у такого сайта нет

У статического сайта нет серверного кода: он не может сам принять форму, поискать по базе или принять платёж. Для этого есть три пути, и вы их уже видели:

• Внешний сервис. Форму принимает сервис форм (и пересылает на почту, в таблицу, в мессенджер), оплату принимает платёжный сервис, поиск строится как индекс, который собирается вместе с сайтом, или как сервис.
• Короткая функция. «Бессерверная» функция (о ней в части 9) запускается по запросу, принимает данные и что-то делает. Это тот же серверный код, только маленький, без сервера, которым вы управляете.
• Своё API. Если логики много (личный кабинет, заказы), то нужен настоящий сервер, и сайт перестаёт быть чисто статическим. Это нормально: Jamstack не догма, а способ вынести на сервер только нужное.

И здесь возвращается тема урока 7 части 7. Любой внешний сервис, который принимает заявку, получает персональные данные посетителей. Вы по-прежнему оператор и отвечаете за них. Нужны согласие и политика рядом с формой, и ответ на вопрос «где сервис хранит заявки, и в какой стране». Для хранения данных граждан РФ это не прихоть, и вы либо выбираете сервис, который хранит в России, либо принимаете заявки функцией на сервере в России. Выбор надо сделать на схеме, а не на самотёке.

Практика

Вы в эпохе 2022 года: сайт собирается по вебхуку из CMS и лежит на CDN. Опишите схему выкладки своего проекта в четырёх шагах (источник, сборка, выкладка, раздача), назовите сервис или функцию, которая принимает главное действие посетителя, скажите, где лягут персональные данные, и как вы откатите неудачную публикацию.

Что было не так

Первые схемы «правка → пересборка» требовали, чтобы разработчик вручную запускал сборку и копировал файлы по FTP: один неосторожный жест, и сайт был наполовину обновлён. Атомарные выкладки хостингов, откат одной кнопкой и вебхуки убрали и эту, и многие другие ручные ошибки.