Преимущества headless CMS: гибкость и масштабируемость

Один набор материалов — разные способы представления. Каждый сайт или приложение всё равно нужно разработать и подключить.

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

Система управления контентом без встроенного слоя представления — headless CMS — разделяет две задачи: хранить информацию в упорядоченном виде и определять, как её увидят читатели. Такое разделение может быть полезным. Насколько — зависит от того, что вам нужно публиковать и кто будет создавать и поддерживать связи между частями системы.

Что на самом деле означает headless?

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

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

Один из примеров — Strapi. Эта система предоставляет интерфейс редактирования, модели контента и API для приложений. API даёт разработчикам доступ к материалам, но не проектирует за них то, как читатель будет с ними взаимодействовать.

Когда гибкость приносит пользу

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

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

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

Какие задачи архитектура не решит за вас

Headless не означает автоматически «быстро». Страницу можно подготовить заранее и быстро отдать читателю, а можно выстроить цепочку медленных запросов, которые должны завершиться, прежде чем на экране что-то появится. Результат по-прежнему зависит от изображений, кеширования, хостинга и устройства фронтенда. Разделение частей позволяет команде выбирать, где повышать производительность и наращивать мощности, но кому-то предстоит сделать этот выбор и проверить его на практике.

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

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

Проверьте весь процесс публикации

1. Выберите один типичный материал: например, анонс выступления с фотографией, датой, описанием и версией на втором языке.
2. Попросите будущего редактора создать черновик и посмотреть, как он будет выглядеть в реальных макетах сайта и приложения.
3. Опубликуйте материал, измените время и проверьте, когда исправление появится на каждой площадке.
4. Восстановите предыдущую версию. Экспортируйте контент и медиафайлы, а затем выясните, что потребуется для их использования в другой системе.

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

Выбирайте архитектуру под задачи публикации

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

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