Headless cms что это

Headless CMS: простое и быстрое решение, когда не хочется сильно лезть в код

Узнаем, что из себя представляют «безголовые» системы управления контентом, и посмотрим, как они работают в реальных проектах.

Николай Ким
Admitad Projects Frontend Developer

Что такое Headless CMS

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

• поддержку баз данных;
• управление пользователями;
• аутентификацию;
• установку ролей и прав доступа.

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

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

Когда Headless CMS будет не самым эффективным решением — альтернативы

На проекте полноценный бэкенд

Headless CMS ориентированы на работу с данными в стиле CRUD. То есть они поддерживают только базовые операции с данными.

Реализовать сложную логику или организовать высоконагруженное приложение — это решение вам не подойдет. Будет проще написать бэкенд самому.

Можно хранить контент в коде проекта

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

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

Можно использовать конструкторы сайтов

И получать все блага подхода WYSIWYG. Плюсы — можно вообще не трогать код и собрать все из готовых блоков. Минусы — реализовать дополнительные функции очень сложно, а иногда просто невозможно.

Выбор подходящей CMS: что нужно знать

Предположим, вы решили попробовать для своего проекта Headless CMS. Всего есть порядка 100 разных Headless CMS. Есть каталог, из которого можно выбрать нужное решение.

Все CMS можно разделить на два типа — API Driven и Git-based.

API Driven Headless CMS похожи на классический бэкенд веб-приложений: есть база данных, есть сервер, который обслуживает запросы клиентов.

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

Некоторые CMS не предоставляют API, но имеют дружественный интерфейс для редактирования данных в Git-репозиториях. Их называют Git-based. Пример — FrontAid. Вначале все изменения пушатся в репозиторий, а затем происходит пересборка сайта или приложения.

• контроль версий для контента такой же, как и для кода;
• контент представлен в виде плоских файлов — с ними проще работать;
• легко откатиться до предыдущей версии;
• легко внедрить.

Основное отличие API-Driven от Git-based в том, как именно будет храниться контент. Например, если вам не нужно публиковать в день десятки страниц или очень часто пересобирать сайт, подойдет решение Git-based. А если нужна полноценная система публикации контента — смотрите в сторону API-Driven.

Пример, как всё работает

Вот одностраничный сайт на Nuxt. Он работает в режиме SSR, то есть клиент получает отрендеренную страницу с готовой версткой.

На нашем сайте можно выделить блоки:

1. Статичный блок текста.
2. Карточки товаров — тарифные планы.
3. Текстовая инструкция.
4. Форма обратной связи.

Сейчас это обычный статичный лендинг. С помощью Headless CMS мы это исправим. Используем сразу две системы:

• FrontAid, чтобы можно было редактировать текстовый блок и карточки тарифов;
• Directus, чтобы собирать данные из формы.

На самом деле можно всё сделать через Directus, поскольку для Nuxt не имеет значения, откуда тянуть данные для сборки статического сайта — из файлов проекта или из API. Но мы посмотрим, как работают оба типа CMS.

FrontAid

Он позволяет редактировать исходный код на GitHub через веб-интерфейс. Нужно подключить FrontAid к репозиторию, объявить формат данных в model.json. По этому описанию FrontAid соберет интерфейс для редактирования. Все данные будут комититься обратно в репозиторий, в файл content.json. Его потом можно будет загрузить в приложение.

Вот как это выглядит на практике. Логинимся на FrontAid, создаём новый проект:

Подключаемся к GitHub, указываем репозиторий, ветку и путь к model.json и content.json.

Вначале нам нужно описать модель данных. Заходим в model.json. В нём уже объявлены поля для примеров. Можно использовать отдельное значение, структуру или коллекцию.

"description" : < ":type": "text", ":rich.text": true >, 

Это наш блок статического текста. Здесь указана опция rich text. Таким образом у нас будет редактор HTML в интерфейсе.

Для карточек будем использовать коллекцию. У нас есть заголовок — title, есть цена — price, есть единица — unit.

"offers": < "items": < "type": "line" >, "price": < "type": "line" >, "init": < "type": "line" >, > 

Мы задали структуру. Если все сделано верно, в интерфейсе FrontAid появятся объявленные поля:

Для примера в блоке описания выделим часть текста жирным шрифтом, часть — наклонным.

Добавим новую услугу — ретушь.

Сохраняем. Данные должны прийти в файл content.json.

Осталось использовать эти данные в шаблоне — index.vue.

Подгрузим файл, который получили из FrontAid строкой

import < offers, description >from ‘~/data/content.json’; 

Сделаем вывод добавленной услуги:

return < prices: [ . sample, . offers, ] >; 

Sample — это уже готовые карточки товаров, они были объявлены ранее через массив.

Описание подключим следующим образом:

Осталось передать изменения:

return < prices: [ . sample, . offers, ] description, >; 

Directus

Это API-based Headless CMS. Разворачивается как отдельное приложение, поддерживает базы данных. Есть веб-интерфейс для настройки и редактирования контента. С API можно взаимодействовать через REST или GraphQL.

Нам нужно настроить модель данных через админ-панель, а потом использовать API из нашего проекта на Nuxt.js. В качестве базы данных будем использовать SQLite. Так выглядит веб-интерфейс Directus:

Слева в меню есть базы данных, список пользователей, медиафайлы, документация и модель данных.

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

Создаём новую коллекцию, называем её responses:

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

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

Вот так будет выглядеть созданная коллекция:

Поскольку отправлять форму могут все, заходим в настройку ролей и для Public ставим разрешение на создание полей Username, Email и Message.

Переходим к наполнению нашей коллекции. Для клиентских приложений Directus предоставляет SDK. Подключается в проект в package.json, подключается командой “@directus/sdk”.

При нажатии кнопки нам нужно создавать новую запись в коллекции responses. Сделаем обработчик в файле index.vue:

methods: < async handleSubmit(data) < try < await this.$directus .items('responses') .createOne(data) alert('Success') >catch (e) < alert(e.toString()) >> > 

Отправляем форму и заходим в нашу коллекцию. Видим ответ:

На самом деле возможность добавлять новые карточки товаров и менять текст можно также реализовать через Directus: завести отдельную коллекцию offers с нужными полями — названием, ценой, единицей измерения.

Заключение

Headless CMS можно быстро внедрить в проект. При этом необязательно писать много кода для бэкенда. Например, для Directus можно обойтись вообще без кода, если вам достаточно базовых операций с данными.

С другой стороны, некоторым решениям недостает функциональности. Модель рассмотренного FrontAid описывает произвольный JSON, и в теории мы можем сделать много вложенных структур, но ими будет сложнее управлять.

Headless CMS — компромисс между скоростью/простотой и функциональностью/расширяемостью.

Что такое Headless CMS?

Впервые такой термин я встретил в 2016 году в блоге Дрис Бёйтарта The future of decoupled Drupal.

Традиционная («монолитная») и headless архитектуры.

Headless означает, что CMS отдаёт не готовый HTML, а только данные, обычно в JSON формате по средствам REST (или GraphQL). В упомянутой статье приводится синоним headless («безголовая») — decoupled («отделенная»).

Тренды

Тенденция генерации HTML на сервере идёт на спад. Современный тренд заключается в построении пользовательского интерфейса полностью на стороне клиента (в браузере). В этом случае HTML создаётся с помощью JavaScript из JSON данных, полученных с сервера. Такие приложения называются одностраничными. Вторым трендом можно назвать развитие конструкторов сайтов и таких площадок как medium.

Традиционные CMS, такие как Drupal или WordPress, имеют функции ядра для организации headless архитектуры. JSON данные постов lifehacker (работающего на wordpress) выглядят так в сравнении с обычной версией. Существуют специализированные headless cms такие как strapi или ghost.

• Желание отделить данные от представления так, чтобы команды frontend’a и backend’a могли работать независимо друг от друга.
• Редакторы и маркетологи ищут решения, которые могут предоставлять контент для растущего списка каналов, включая веб-сайты, одностраничные приложения, нативные приложения для телефонов, сервисные системы, чат-боты, а также носимые устройства (часы, фитнес-браслеты, пульсометры), IoT, устройства с голосовым управлением.

Вместо заключения

• https://headlesscms.org/
• https://dri.es/how-to-decouple-drupal-in-2019

Другие записи из подборки «Исследования CMS»

На каких CMS сделаны самые популярные сайты рунета?

Представлены данные топ 100 сайтов рунета по посещаемости (по данным LiveInternet) на 2012 год и дан ответ почему CMS редко используются для больших проектов.

27 сентября 2017 г. в Общее

Анализ шрифтовых пар на сайтах ведущих СМИ РФ

Представлены CSS свойства шрифтов заголовка и основного текста для отдельной статьи.
05 января 2018 г. в Общее

Позиции российских CMS в мировом рейтинге w3techs

Анализ популярности российских CMS в рейтинге w3techs на февраль 2018 года
15 февраля 2018 г. в Общее

Похожие записи

Что такое PostCSS?

Определение PostCSS, принцип работы ядра и важные плагины
08 октября 2017 г. в Обучение

Кратко о внедрение зависимостей и сервис контейнере

Cтатья о том, что такое «Внедрение зависимостей» и «Сервис-контейнер» отталкиваясь от их реализации в PHP фреймворках. Статья написана по мотивам статей Фабьена Потенсье, ведущиго разработчика и идеолога фреймворка Symfony, а также документации фреймворка Laravel.

18 сентября 2017 г. в PHP, Обучение, Общее

Создание объектов PHP в стиле JS литеральной нотации

В JavaScript объекты можно создавать несколькими способами, основные: оператор new и литеральная нотация. В статье рассказывается как в PHP создавать объекты в стиле JavaScript литеральной нотации.

24 сентября 2017 г. в PHP, Обучение

Практика использования MVC

В статье говорится о правильной организации кода моделей, контроллеров и представлений в шаблоне MVC
21 октября 2017 г. в Laravel, PHP, Обучение

Нестандартный checkbox

Видео про создание кастомного чекбокса

20 февраля 2019 г. в Обучение

О слайдах

Youtube видео. Мастер-класс Алексея Каптерева «О слайдах», почему большинство презентаций со слайдами — очень скучные и запутанные, и о том, как превратить ваши слайды из ваших противников в ваших союзников.

18 февраля 2018 г. в Обучение

© 2017-2020 — Александр Ветров

Сайт работает на October CMS

Что такое Headless CMS и почему за ними будущее

Чтобы добиться успеха, бизнес открывает представительства в Сети, запускает мобильные приложения, позиционируется в социальных сетях, использует «умные» гаджеты и устройства интернета вещей. Важно как можно шире представить себя на рынке, используя все доступные способы. А еще необходимо быть гибким, быстро и легко мигрируя на новые платформы.

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

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

Headless CMS — тело без головы

Логика традиционных CMS объединяет бэкенд- и фронтенд-части одной системы. Контент в данном случае оказывается связан с конкретными технологиями, архитектурой и шаблонами клиент-серверного приложения.

Headless CMS — принципиально иная система управления. Как правило, она отвечает только за универсальное содержимое, которое может использоваться на любых платформах. Бэкенд («тело») при таком подходе не связан с фронтендом («головой»).

Логика Headless CMS такова, что к «телу» при необходимости можно приставлять разные «головы». Это позволяет использовать один бэкенд для управления сайтом (или сайтами) и мобильным приложением, а также автоматизировать распространение контента по всем доступным площадкам и устройствам.

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

Как это работает

Как уже было сказано, Headless CMS предполагает управление только контентом независимо от интерфейса, в котором он будет использоваться (представляться конечному пользователю).

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

Содержимое системы хранится в поддерживаемой ею базе данных (PostgreSQL, MongoDB, SQLite, MySQL и MariaDB в Strapi). Обмен данными чаще всего происходит в «универсальном» формате JSON, что позволяет подстраиваться под любой новый фронтенд. Передача осуществляется через внешний API: RESTful или GraphQL.

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

Преимущества Headless CMS

Главная ценность подхода, реализованного в Headless CMS — омниканальная готовность. Контент в универсальном формате можно использовать на сайте, в мобильном приложении, в интерфейсе различных цифровых устройств. Это расширяет возможности бизнеса, позволяет гибко использовать разные решения (интегрируя их по очереди или сразу задействовав все необходимые).

Снижение затрат на разработку — второе важное преимущество. При определенных условиях Headless CMS дешевле в установке и настройке. Разработчикам не требуется осваивать систему управления «от и до», достаточно разбираться в административном интерфейсе и API.

Ускорение реализации новых проектов — тоже немаловажный плюс для бизнеса. Благодаря гибкости использования контента, в Headless CMS процесс запуска сайта или приложения занимает меньше времени. Кроме того, индустриальные стандарты RESTful и GraphQL обеспечивают быстрый старт при развертывании нового проекта: разработчикам не требуется закладывать архитектурные основы и осваивать тулинг вокруг этих технологий.

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

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

Содержимое легко переносится в новые интерфейсы. Например, для реализации приложения для iOS, при наличии web- и Android-версий, не требуется создавать новый бэкенд — к существующей схеме просто добавляется еще одно клиентское приложение.

При этом разработчики на любом языке программирования (Ruby, PHP, Java, Swift) могут использовать API при манипуляциях с системой, решая таким образом проблему несовместимости разных языков в одном продукте. Это дает возможность задействовать новейшие технологии и креативно подходить к процессу разработки.

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

Есть ли недостатки у Headless CMS?

Переход к логике Headless CMS предполагает знакомство с ее принципами и технологиями, однако разработчику достаточно иметь базовый уровень знаний сетевых технологий.

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

Headless CMS обеспечивает только бэкенд, поэтому фронтенд-архитектуру необходимо реализовывать с помощью дополнительных ресурсов. Но существуют продукты вроде Gatsby, Nuxt, VuePress, Hugo и Gridsome, которые обеспечивают упрощенную интеграцию с CMS.

Виды Headless CMS

Существует множество CMS, поддерживающих логику Jamstack. Суть подхода заключается в предварительном рендеринге файлов и их передаче непосредственно с CDN, минуя веб-сервер.

Все такие CMS представлены на сайте headlesscms.org. Большинство из них являются open source решениями.

Headless CMS могут предполагать самостоятельное развертывание на сервере или выгрузку на CDN-сервис.
Некоторые системы работают через клауд-провайдеров.
Многие поддерживают создание модели и последующее заполнение ее контентом.
Еще один критерий выбора: использование GraphQL или REST API (или оба вида в одном продукте).

Почему будущее — за Headless CMS

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

С дальнейшим развитием цифровых продуктов Headless CMS, вероятно, будут все более предпочтительны, нежели традиционные WordPress или Joomla. Есть все основания полагать, что будущее — именно за «безголовыми» системами.

• Headless CMS
• CMS
• веб разработка
• управление сайтом

Для каких задач подходят Headless CMS, и как с их помощью сокращается time-to-market разработки

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

Что такое Headless CMS?

Headless CMS – это гибкая система управления контентом с удобным интерфейсом редактирования. Headless CMS позволяет отображать контент омниканально через API. Например, на сайте, в мобильном приложении, емейл рассылке и голосовом помощнике.

От стандартных CMS Headless отличается тем, что работает с разными типами фронтендов и любыми типами интерфейсов и устройств. Так получаем единый источник «правды» и не занимаемся переносом контента между разными системами.

В Headless CMS мы создаем только интерфейс для редактирования контента. Система по умолчанию ориентирована на хорошо структурированный контент, поэтому в результате получаем удобные для восприятия форматы на любых типах устройств.

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

Headless CMS бывают облачные и on premise – те, которые можно поставить на свою инфраструктуру (сервера и БД). Если CMS облачная, получаем масштабируемую систему для редактирования и выдачи контента – не нужно заниматься поддержкой и администрированием ее инфраструктуры. Это очень удобно.

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

Похожие на Headless CMS решения

Первое и наиболее близкое к Headless CMS – генераторы админок для различных языков программирования и платформ разработки. Например, для Python есть Django, а на языке PHP есть Laravel Nova. Они подойдут для случая, когда вы уже разрабатываете приложение на этом языке, и нужно быстро добавить возможность администрирования для отдельных частей. Они не такие удобные для редактора, как Headless CMS.

Второе – Backend-as-service. Например, Firebase, Supabase ли Amazon Amplify – они обычно используются для мобильной разработки, чтобы не писать отдельно бэкенд, а брать платформу. Они выдают API для типовых операций: сохранение и управление данными пользователей, логина, регистрации и отправки push-уведомлений, но не дают интерфейса для администрирования.

Backend-as-service подойдет, например, если мы делаем приложение для ведения задач (to-do лист) и хотим, чтобы пользователи могли регистрироваться и синхронизировать свои задачи на разных девайсах. То есть для сервиса не требуется какой-то сложный интерфейс администратора, ведь все данные создают сами пользователи.

Третье – это полноценные no-code/low-code платформы для создания приложений. В них можно визуально создавать админки, веб-, и мобильные приложения. Некоторые такие платформы (например, Retool) похожи на Headless CMS тем, что позволяют создать произвольный интерфейс админки и отдавать данные через API для других потребителей.

Создаем свой сервис: варианты реализации

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

Нам нужно реализовать landing page с основной информацией о нашем сервисе, где будет публиковаться и изменяться контент, помогающий продавать наш продукт.

Сервис будет работать в виде мобильного приложения на iOS и Android.

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

Традиционный путь

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

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

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

Путь с Headless

Мобильных разработчиков все еще придется нанять, ведь наш основной продукт – приложение. Остальной процесс будет другим: ускоряем time-to-market.

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

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

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

Про временные разницы. Собрать структуру контента и админку для такого продукта получается быстро. У меня это заняло это 1.5 часа.

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

Преимущества Headless

Про ускорение time to market поговорили, теперь – о других преимуществах.

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

Для разработчиков — более чистая архитектура за счет разделения ответственности в частях. Разработчикам удобно отделять бэкенд (контент) от фронтенда (того, как контент отображается). Можно сконцентрироваться на своей части и не вникать в другие части продукта.

Для руководителей плюс организационный: нужно меньше людей и нет потребности нанимать ребят-единорогов, которые могут все и сразу. Когда продукту нужно сделать MVP, обычно нанимают суперфуллстека, который разрабатывает все: бекенд, фронтенд, мобилку. Такие ребята есть, но их тяжело найти, и чем больше растет проект, тем тяжелее его поддерживать. А если использовать хэдлесс, всезнающего человека искать не нужно. Чтобы сделать сайт на headless, достаточно компетентного фронтенд разработчика со знанием CSS/JS.

Headless CMS легко можно интегрировать с другими платформами и пользоваться лучшими из них в своем классе. Например, когда мы разрабатывали ecommerce проект на headless CMS, часть проекта, включающая каталог и продажи использовала Shopify – ведущую ecommerce платформу с удобными интерфейсом. В итоге наш заказчик получил лучший интерфейс для управления контентом и лучший интерфейс для обработки заказов и управления каталогом.

И финальное – удобство редактирования контента. Многие headless CMS (например, Ghost или Kontent.ai) предоставляют крутой UX для скорости и удобства редактирования — хорошо подходит для онлайн-медиа или если вы пишете и публикуете много статей и делаете визуал.

Для чего не подойдет Headless CMS

Во-первых, для реализации сложных бизнес-процессов, воркфлоу и интерфейса за рамками публикации контента. Headless CMS хорошо реализуют сценарии создания и редактирования контента, его публикации (а еще утверждения и перевода), различные права доступа к разному типу контента. Но они не помогут сделать, например, свою CRM систему заточенную под ваш бизнес. Для такой задачи лучше посмотреть в сторону no-code платформ или пойти по традиционному пути, и сделать большую самописную систему, если пророчите проекту большое развитие.

Headless CMS не подойдут для хранения и управления огромными массивами данных. Например, у нас был проект, где в headless CMS был архив из 600+ тысяч статей — это реально. Но не стоит рассматривать headless CMS, как замену обычной базе данных и пытаться хранить там какие-то транзакции пользователей или что-то, что очень часто обновляется — например, биржевые котировки.

Риски Headless CMS

Главный — вы зависите от вендора CMS, и того, как он будет развивать продукт. Это особенно актуально для облачных CMS: могут поменять интерфейс и сделать его перегруженным и неудобным, поменять тарифы, или вообще закрыться.

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

Этот же способ помогает ответить на вопрос: «А что, если мне в будущем станет недостаточно возможностей CMS, и я захочу перейти на свою платформу?». Можно разработать свою платформу, перенести структурированные данные из API в нее и даже сохранить структуру API! То есть не придется переделывать приложения, которые использовали контент.

Защитится от изменений в функциональности продукта можно, используя не облачные, а on premise платформы. Однако и тут будут свои минусы — нужно будет самостоятельно поддерживать инфраструктуру для них. Также есть платформы Strapi, Ghost и Umbraco, которые позволяют начать работать на облачной версии, но при желании переехать на open source версию, которую можно будет развернуть на своей инфраструктуре.

Полезные ссылки

Подробнее ознакомиться с изобилием различных CMS поможет этот список. В нем можно настроить фильтрацию по типу CMS и типу ее доступности. Внутри – описание каждой CMS с примерами интерфейсов и оценкой.

Есть и другой список, но уже с более детальной фильтрацией: по бизнес-сегментам, рейтингу, доступным языкам, ценам и функциям.

• headless cms
• сокращение расходов
• разработка сайтов
• разработка приложений
• cms
• сервисы для разработки