При обсуждении проектов в первую очередь думают об удобстве конечного пользователя и редко об удобстве администраторов. Вопросы управления сайтом часто откладываются на последний момент. При этом выбор системы управления контентом — важный параметр, от которого зависит бюджет проекта на всех этапах его жизненного цикла.
В этом материале мы расскажем о технологии, которая эту проблему решает — Headless CMS. А также о том, как внедрили ее на проект нашего клиента.
О клиенте
CarPrice — российский сервис по продаже подержанных автомобилей через онлайн-аукцион.
Цели и задачи
Переработать существующий сайт, чтобы пользователям было проще узнавать, как сервис решит их задачи. Для этого нужно постоянно добавлять новый контент и контролировать его актуальность. Привлекать для этого каждый раз IT-специалистов затратно. Чтобы добиться этой цели, приняли решение внедрить CMS.
Риски и ограничения
Проект разрабатывают совместно внешняя команда и штатный отдел: первые отвечают за интерфейсную часть, а последние— за серверную. При внедрении CMS фронтэнд- и бэкенд-разработчики должны постоянно взаимодействовать, чтобы оперативно разрешать возникающие с той или иной стороны вопросы и не тормозить процесс. В случае нескольких отдельных команд взаимодействие организовать сложнее — есть риск увеличения сроков из-за ситуаций, когда одна команда ожидает наработок другой, чтобы продолжить работу.
Решение
С одной стороны, система должна позволять оперативно управлять контентом без привлечения программистов, а с другой, не требовать значительных временных затрат на внедрение.
Для минимизации затрат выбрали Headless CMS. В отличие от традиционных коробочных систем, здесь бэкенд- и фронтенд-части не объединены логикой. Отсюда и название «тело без головы», где «тело» — это серверная реализация, а «голова» — интерфейсная.
Преимущество в том, что система отвечает только за контент— ей неважно, где и каким образом он будет отображаться. Обычно данные в этом случае передаются через API в формате JSON, а фронтэнд-разработчик самостоятельно интегрирует их в имеющийся интерфейс. Таким образом, Headless CMS подойдет под любые фронтэнд-технологии.
Из доступных Headless CMS выбор остановился на Strapi, у которой 33,5 тысяч звезд на GitHub на момент публикации. Это полностью бесплатный продукт с открытым исходным кодом, предоставляющий удобный административный интерфейс для управления контентом, с помощью которого можно быстро создать необходимое API.
Strapi разворачивается на сервере компании и позволяет использовать дополнительные плагины для расширения функционала. Также в Strapi есть удобный визуальный текстовый редактор— на фронтэнд текст передается в формате markdown. Контент-менеджеру можно абсолютно не переживать о правильной расстановке HTML-тегов.
Предварительная подготовка
В первую очередь мы проанализировали возможности, которые предоставляет Strapi, и сопоставили их с потребностями клиента.
Strapi позволяет создать два типа моделей:
- Модели типов контента (коллекции и единичные типы). Данные, представленные в этих структурах, доступны непосредственно через API.
- Модели компонентов. Компонент — это структура данных, которая используется в одной или нескольких моделях типов контента.
Коллекции — это совокупность данных по однородным элементам. Например, у компании существует несколько подразделений, у каждого из которых свой адрес, телефон, часы работы и пр. Такие данные удобно хранить в виде коллекций. Каждый элемент коллекции в данном случае будет описывать конкретное подразделение. Он обладает своим набором полей, который задается при создании модели этой коллекции. Контент-менеджер в дальнейшем может добавлять новые элементы в коллекции, редактировать или удалять их.
Единичные типы описывают данные по уникальным элементам. Например, это могут быть страницы сайта, для каждой из которой задается свой индивидуальный набор полей. Также единичные типы можно использовать для отдельных блоков сайта, которые являются «сквозными» для всего проекта, то есть подключаются на разных его страницах с неизменными данными — например, показателями деятельности компании. Визуальное отображение таких блоков при этом необязательно должно быть одинаковым для всех страниц — CMS предоставляет только данные, а как их отрисовывать, решает фронтенд.
Компоненты — одиночные или повторяющиеся сущности, которые используются в качестве одного из типов полей в коллекциях и единичных типах контента. Например, это может быть блок, содержащий картинку и текст, который можно переиспользовать в других компонентах или типах контента, или блок, описывающий структуру слайда для слайдера.
Создавать эти модели можно прямо через административный интерфейс Strapi. Вот так, например, может выглядеть структура модели для единичного типа контента— блока со списком документов, которые необходимы для оформления сделки:
Здесь структура блока представлена текстовым полем для заголовка и повторяющимся компонентом, который в этом конкретном блоке называется Document и представляет собой ранее созданный базовый компонент TextWithIcon. Этот компонент содержит поля для прикрепления файла иконки и текстовой подписи, его можно переиспользовать в других компонентах:
А таким образом выглядит этот блок в режиме редактирования контента:
В таком интерфейсе просто разобраться, не имея технических знаний.
Изучив возможности Strapi, мы проанализировали список компонентов сайта, которые необходимо было сделать редактируемыми, и разделили эти компоненты на «сквозные», т.е. используемые с одними и теми же данными на разных страницах сайта, и «персональные», данные в которых отличаются для разных страниц.
После этого спроектировали структуру данных для админ-панели, разделив их на коллекции, единичные типы и компоненты. Для каждой коллекции, единичного типа или компонента обозначили, за какие блоки на сайте они отвечают, и подробно описали набор полей для них и назначение каждого поля. Эта схема стала подспорьем не только для разработчиков, создававшим на ее основе структуру данных в админ-панели, но и для контент-менеджеров, позволяя проще и быстрее ориентироваться в интерфейсе.
В процессе проектирования структуры данных столкнулись с ограничением— Strapi не поддерживает глубокую вложенность компонентов. Так, например, на условную страницу может быть подключен компонент, у которого есть дочерние компоненты. Но у них при этом своих дочерних компонентов («внучатых» для первого) быть не может. Из-за этого ограничения пришлось откорректировать изначально планируемую структуру данных, после чего проблема решилась.
Интеграция
В процессе интеграции мы убедились в правильности решения выбрать Headless CMS. Внутренняя команда клиента развернула на сервере админ-панель Strapi, создала учетную запись для пользователя внешней команды и настроила необходимые доступы.
Всю остальную работу выполняла внешняя команда. При этом, если в процессе разработки возникала необходимость подкорректировать структуру данных для удобства, это делалось «на лету», без привлечения бэкенд-разработчиков.
Мы создали через административный интерфейс Strapi все необходимые компоненты и типы контента и наполнили их данными для демонстрации работы сайта.
После создания типов данных им автоматически присваивается эндпойнт, по которому можно запросить информацию о соответствующей коллекции или единичном типе.
После настроили доступы к этим данным извне. По умолчанию в Strapi предусмотрено две роли — для авторизованных и неавторизованных пользователей. Для каждой из ролей можно настроить отдельные доступы к данным, в том числе для разных действий. Например, какую-то персонализированную информацию могут просматривать только авторизованные пользователи, а общую — все. Это касается и прав на редактирование контента.
Чтобы настроить доступы для каждой роли в административном интерфейсе Strapi, нужно только проставить галочки напротив соответствующих пунктов:
Неавторизованным пользователям мы дали доступы на получение всей информации, необходимой для отрисовки сайта, т.к. никакие персональные данные для этого не использовались.
Всего за две недели клиент получил возможность оперативно управлять контентом сайта, не привлекая к этому IT-специалистов. При этом те же самые данные могут использоваться не только на сайте, но и в мобильном приложении, а также в других проектах клиента без дополнительных вмешательств в бэкенд.
В перспективе можно увеличить «управляемость» сайта с помощью интеграции новых компонентов, и это также можно сделать только силами фронтенд-разработчиков, что значительно снизит как временные, так и денежные затраты на внедрение нового функционала.
