Headless CMS: что это, как устроена и когда её выбирать

Как устроена headless-архитектура

Слово head здесь означает слой представления: шаблоны, вёрстку, всё, что видит посетитель. У headless-системы этого слоя нет. Внутри остаются модели контента, админка для редакторов, роли и права, медиатека. Наружу она смотрит через API.

Фронтенд пишут отдельно, на React, Vue, Next.js, Nuxt или как мобильное приложение. Один и тот же источник контента может кормить сайт, приложение, экран в торговом зале и рассылку. Редактор меняет текст один раз, а все каналы получают его сами.

REST и GraphQL

Почти все такие системы отдают данные по REST: каждая сущность живёт по своему адресу, ответ фиксированного вида. Многие поддерживают и GraphQL — язык запросов, который Facebook использовал внутри с 2012 года и открыл в 2015-м. В нём клиент сам перечисляет нужные поля и получает связанные данные одним запросом, без лишнего.

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

Монолитная, decoupled и headless: в чём разница

Монолитная CMS, как WordPress или 1С-Битрикс в классическом виде, хранит контент и сама же рендерит страницы по шаблонам. Decoupled-система тоже умеет рендерить, но вдобавок отдаёт данные по API, и часть интерфейса можно сделать отдельно. Headless-платформа шаблонов не имеет вовсе: фронтенд всегда внешний.

Сравнение подходов

Удобнее всего различия видны в таблице. Я бы смотрел прежде всего на состав команды: он определяет и смету, и скорость доработок.

Какие бывают headless-системы

Их условно делят на открытые, которые разворачивают на своём сервере, и облачные сервисы с оплатой по подписке.

• Strapi — open source на Node.js. Ставится на свой сервер, типы контента собираются в админке, есть REST и GraphQL.
• Directus — open source, надевает API и админку поверх существующей SQL-базы.
• Payload — open source на TypeScript, вся конфигурация описывается кодом.
• Contentful — облачный сервис с REST и GraphQL API.
• Sanity — облачное хранилище контента и редактор Sanity Studio на React, для запросов есть свой язык GROQ.

Своя установка или облако

Облачный сервис снимает заботу о серверах, но данные лежат у поставщика, часто за рубежом. Для обычного контента это не страшно. Если же через систему проходят персональные данные граждан России, вспоминайте часть 5 статьи 18 закона 152-ФЗ: их первичный сбор и хранение должны идти на серверах в России. В таких проектах я бы выбирал открытую систему на своём сервере.

SEO и скорость: SSR и SSG

Главный страх при переходе на отдельный фронтенд — индексация. Если страница собирается только в браузере, поисковик может увидеть пустой шаблон. Решают это рендерингом на сервере.

Next.js для React и Nuxt для Vue умеют SSR — собирать HTML на сервере в момент запроса — и SSG — генерировать статические страницы заранее, при сборке. В Next.js есть ещё ISR: статическая страница пересобирается по таймеру или по событию, когда редактор поменял контент. С такими фреймворками сайт получает готовый HTML, нормальные мета-теги и быструю отдачу, то есть с точки зрения SEO не уступает монолиту.

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

Когда headless-подход оправдан

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

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

Как перейти на headless-подход без большого переписывания

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

Главный риск при переезде — SEO. Адреса страниц, мета-теги, микроразметка и редиректы должны совпасть со старым сайтом, иначе позиции просядут на несколько месяцев. Поэтому карту адресов я бы сверял ещё до запуска нового фронтенда.

• Описать модели контента: какие сущности есть, какие у них поля и связи.
• Открыть данные через API и проверить, что ответы покрывают все экраны.
• Перенести на новый фронтенд один раздел, например блог или каталог, и сравнить скорость и индексацию.
• Настроить предпросмотр для редакторов до того, как переводить весь контент.
• Переводить остальные разделы по одному и отключать старые шаблоны в конце.

Битрикс в роли headless-системы

Битрикс изначально монолит, но у него есть REST API, а инфоблоки — гибкая модель контента. Если отдать их наружу через настраиваемое API, фронтендер сам создаёт структуру инфоблоков и пишет интерфейс на React или Vue, а бэкендер не тратит время на очередное API в десятый раз. Именно такой модуль мы и решили сделать, причём открытым и бесплатным.