Headless CMS: когда контент отделён от сайта

Headless CMS — система управления содержимым без собственного сайта: редактор правит записи в админке, а сайт и приложения получают их по API.

Когда сайт и админка срослись

Обычная CMS, такая как WordPress, это монолит: админка, хранилище и сайт (тема) в одной программе. Это удобно, пока вам нужен один сайт именно такой. Но представьте, что вы хотите написать сайт на современном инструменте из прошлого урока, а для редактора оставить привычную админку. Или показать одно и то же содержание на сайте и в мобильном приложении. Монолит такого не даёт: сайт и админка у него неразлучны.

Без головы

Headless CMS (безголовая CMS) разрезает монолит. «Голова» это то, что показывает содержание посетителю: тема, сайт, приложение. Её отрезают, остаётся «тело»: хранилище, админка и API (REST или GraphQL, о них мы говорили в части 6). Сайт, приложение или что угодно ещё запрашивает содержание у API и рисует как хочет.

Что получаем:

• Свобода сайта. Его пишут на любом инструменте, который умеет читать API, например на генераторе из урока 5.
• Один источник, много каналов. Те же записи показывают сайт, приложение, голосовой помощник.
• Удобная админка для редактора: форма с полями, а не файлы и Git.
• Безопасность. Админка и хранилище не торчат наружу вместе с сайтом, а сайт может быть статическим.

Чем платим:

• сайт надо построить: в WordPress он был в комплекте;
• появляется ещё одна система для обслуживания и связи с сайтом (урок 7);
• предпросмотр правок («как это будет выглядеть») не работает сам собой, его надо настраивать;
• цена облачных сервисов растёт с числом редакторов и запросов.

Тип, записи и запрос

Работа с headless CMS начинается с модели контента из урока 1. Для услуги вы создаёте тип (его называют ещё content type или схемой): список полей и их типов.

{
  "type": "items",
  "fields": { "title": "string", "text": "text", "price": "string" }
}

Редактор заполняет форму по этой схеме и сохраняет записи. Сайт запрашивает их у API, и в ответ приходит JSON с теми же именами полей:

const response = await fetch('/api/items');
const items = await response.json();   // [{ title: '…', text: '…', price: '…' }, …]

Этот запрос вам знаком по части 5. Сайт либо делает его в браузере при открытии страницы, либо делает при сборке и вкладывает результат в готовый HTML (так поступают генераторы, урок 7). Для двух языков поля повторяют (title_ru, title_en) или делают перевод записи, связанный с оригиналом: в API они приходят под своими именами, и сайт выбирает нужное.

Проверьте себя: что изменится на сайте, если в CMS поправить цену?

Сама цена изменится в записи. Сайт увидит новую, когда сделает следующий запрос или когда будет пересобран (в зависимости от схемы). Правку текста делает редактор, код сайта не трогает никто.

Где живёт содержание: пять систем и три места

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

Файлы в GitБаза на своём сервереОблачный сервис

Примеры: Decap CMS (прежде Netlify CMS). Тексты лежат файлами Markdown и JSON в репозитории рядом с сайтом.

1. Редактор правит запись в админке Decap
2. Decap делает коммит в репозиторий
3. Сборка видит коммит и пересобирает сайт
4. Новая версия выложена

Дальше по пути правки Сначала

Что хорошо

• Нет ни сервера, ни базы: нечего обслуживать и взламывать
• Вся история правок в Git
• Бесплатно или почти

Чем платим

• Редактору нужен вход через Git-сервис
• Сложные связи между записями неудобны
• Каждая правка это пересборка сайта

Текстовая альтернатива: Headless CMS хранит содержание в одном из трёх мест: файлы в Git (Decap), база на вашем сервере (Strapi, Directus), облако провайдера (Sanity, Contentful). Правка редактора проходит путь от админки через хранилище к API или сборке и до сайта. Чем ближе к вам хранилище, тем больше контроль над данными и работы по обслуживанию.

• Файлы в Git: Decap CMS (прежде Netlify CMS). Админка редактирует файлы Markdown и JSON прямо в репозитории сайта, каждая правка это коммит. Серверов нет, цена нулевая, история в Git. Подходит маленьким проектам.
• База на вашем сервере: Strapi и Directus. Strapi написан на JavaScript, в нём вы описываете типы мышкой, и он сразу даёт API. Directus надстраивается над обычной SQL-базой (вспомните часть 7) и показывает её в админке с API. Данные у вас, роли и связи сложные, зато сервер, обновления и защита на вас.
• Облако: Sanity и Contentful. Sanity предлагает «студию» для редакторов, встроенную в ваш проект, и свой язык запросов. Contentful облачная служба для крупных команд. Старт быстрый, предпросмотр и совместная работа встроены, а содержание хранит провайдер. Для проекта с персональными данными это вопрос (часть 7), а цена растёт вместе с проектом.

Мы не называем цен: они меняются, а смотреть их надо на сайте самого сервиса.

Как выбирать

Три вопроса, как и раньше: сколько редакторов и кто они, какой бюджет, что за данные в записях. Один редактор и маленький бюджет: Decap или даже просто файлы. Нужны сложные связи, роли и данные в России: свой сервер. Много редакторов, быстрый старт, данных о людях в записях нет: облако. Решение принимается в уроке 8 вместе с остальными.

Практика

Вы в эпохе 2022 года: сайт и содержание разошлись по разным сервисам. Опишите тип содержания для услуги, внесите запись и напишите запрос, который выводит услуги на страницу. Сервер имитирован, потому что песочница не пускает в сеть, но запрос ровно такой, как был бы настоящим. Выберите, где жила бы ваша CMS, и объясните выбор.

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

Первые «безголовые» сервисы были иностранными облаками, и для проектов с персональными данными или платежами из России это порождало вопросы к месту хранения и оплате. Поэтому российские команды часто берут открытые системы (Strapi, Directus) и ставят их на свой сервер. Заранее спросите у себя, где лежат данные и кто может перестать их отдавать.