CMS для управления контентом мобильного приложения и сайта

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

Преимущества и недостатки использования CMS для веб-сайтов и мобильных приложений

Если мы говорим о различиях, скажем, приложения без CMS и приложения с CMS, то основными преимуществами CMS являются:

1) Более низкий порог входа для создания сайта. Будь то традиционные CMS или headless CMS, система предназначена для удобства управления контентом. Под коробкой могут скрываться ещё различные плагины для интеграции с системами, например, файловых хранилищ (AWS S3, Minio). В случае традиционной CMS она даже поможет тебе с самим отображением сайта (с созданием страниц). В случае headless CMS это обычно полноценная реализация взаимодействия с СУБД и поддержка различных вендоров СУБД (MS SQL, postgre и другие). Многие типичные задачи манипулирования контентом на сайте упрощаются или вовсе решаются полностью с помощью CMS.

2) Расширяемость. Правда, в традиционной CMS это заключается в прямом расширении сайта, т.е. добавлении новых страниц, а вот в кейсе headless CMS – это лишь расширение источника данных и его моделей (или, конкретней, таблиц в выбранной БД), для которого потребуется код на Frontend’е для отображения, зато headless CMS отлично справляется с задачей добавления однородного контента (новости, рекламные баннеры, в общем, все, что можно привести к массиву однородных сущностей).

3) Скорость. Частично, следствие первого преимущества. Обычно, использование опытными разработчиками CMS позволяет им ускорить общую работу и выпуск новых фич.

А вот основными недостатками являются следующие:

1) Гибкость общей архитектуры. Какую систему управления содержимым сайта CMS ни выбирай, она накладывает особенности архитектуры приложения и особенности разработки. Со временем эта архитектура может легко разрастись и увеличить тем самым требования к компетентности разработчика и усложнить поддержку. Для небольших сайтов традиционная CMS вполне может быть единственным большим звеном в архитектуре, т.к. выполняет все требования. Но чем больше сайт и нетривиальней задачи, тем больше шансов, что будут появляться интеграции. В таком случае CMS может оказаться «слабым звеном» и усложнить процесс расширения архитектуры в разы.

2) Ограниченность как инструмента. Это не недостаток системы, а, скорее, следствие частого заблуждения. Любая CMS прекрасно решает типичные задачи на сайте по манипулированию контентом, но вот с нетипичными задачами она не справится. Поэтому сам факт использования CMS должен быть результатом решения конкретной задачи. Например, во время набирающих популярность headless CMS это бы означало требование использования для манипуляций с однородным контентом, но никак не реализацию конструктора страниц.

3) Отказоустойчивость. Используя CMS, мы подписываем себя на использование коробочного решения как поставщика наших данных. Естественно, в случае слабой производительности и отказов CMS это приведет к полной недоступности данных, а иногда и всего приложения. Где-то здесь ещё стоит упомянуть, что в этой коробке вполне могут существовать уязвимости, а о том, насколько это плохо для нашего источника данных, всем понятно :) Все вышесказанное немного облегчается, если CMS с открытым исходным кодом, но в случае проприетарного решения процесс восстановления работы может занять продолжительное время

Какие типы CMS наиболее популярны и почему?

Как мы уже говорили ранее, выделяют традиционные и headless CMS. Первые – это, обычно, более старые представители. Их особенность в том, что они, помимо управления данными, позволяют ещё контролировать и отображение страниц. Обычно это представляется каким-то html конструктором или прямым редактором html.

Headless CMS – это системы без возможности контролировать отображение страниц сайтов напрямую. Обычно это реализация API для взаимодействия с любой СУБД и вспомогательными системами (файловым хранилищем) + ролевая модель, ограничивающая такое взаимодействие. Иногда ещё реализуется админское приложение для проведения взаимодействия с СУБД через UI из коробки. Впоследствии задача реализации отображения ложится на frontend-разработчика отдельного веб-сайта, который будет использовать headless CMS, по сути, для интеграции по API.
Еще пару лет назад headless CMS не были сильно популярны в российском сегменте и использовались в основном в аутсорс-разработке, российские заказчики предпочитали традиционные CMS. Сейчас же использование headless CMS увеличивается во всем мире. 

На что следует обращать внимание при выборе CMS?

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

Если задача стоит в долговременной поддержке однородного контента (скажем, добавление новостей на сайт), то где-то здесь должна быть headless CMS, которая эту задачу прекрасно выполняет. В этом случае стоит выбирать из готовности коробочного админского приложения, удовлетворения этой админки требованиям заказчика и из быстродействия самой CMS.

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

Примеры успешного внедрения CMS из нашей практики

Сайт для страховой компании ВСК

Первый пример – сайт ВСК. На первых этапах обсуждения проекта было поставлено требование полного управления контентом сайта из админского приложения. Также планировалось создание ~30-40 однотипных страниц, которые мы позже назвали «продуктовыми», т.к. они представляют собой некую презентацию конечного продукта. Мы предложили создать полноценное Frontend-приложение на Angular и использовать Directus CMS ради, собственно, CMS и админки. Directus CMS является headless CMS, т.е. не реализует отображение сайта, следовательно, мы были более свободны в подготовке дизайна сайта.

С другой же стороны, это означало использование API для диктования контента сайта, т.е. все ссылки и их тексты, все кнопки, все абзацы, все картинки, которые можно увидеть на сайте даже сейчас, вероятнее всего, приходят из CMS. Чтобы наполнить даже примитивную страницу, нужно было создать отдельную модель (таблицу в БД), заполнить единожды и потом забирать ее при заходе на эту страницу, а из приложения сайта необходимо выполнить верстку, т.е. создать структуру страницы, а потом сказать какой блок откуда берет информацию из ранее заполненных данных. В разрезе же продуктовых страниц получилось довольно неплохо. Хоть и модель не самая простая, зато эти продуктовые страницы можно было создавать прямо в админском приложении. Масштабирование SSR движка и CMS требует большого количества ресурсов. Вместо этого для оптимизации нагрузки используется несколько уровней кэширования, об этом подробнее мы рассказали в одной из статей.

Как итог - «панацеи не бывает»: хоть в данном случае использование CMS для контроля всего сайта было неоспоримым требованием, но на данном примере этот недостаток headless CMS стал более очевидным :)

Больше про приложение ВСК мы писали тут:

Как клиенты ВСК урегулируют убытки по каско в приложении ВСК Страхование; 

ВСК Онлайн: первое в России страховое приложение с электронным европротоколом

Сайт True Engineering

Другой пример использования – наш собственный сайт True Engineering. На сайте на протяжении долго времени существовала традиционная CMS, разработка на которой была довольно специфичной. С задачей редкого небольшого исправления на страницах она вполне успешно справлялась, но все равно требовала привлечения разработчиков. В последствии запланировалось создание новых страниц на сайте, и мы решили перенять опыт с ВСК сайта для использования Directus CMS на нашем продуктовом ТЕ сайте.
Сильного новаторства в подходах здесь не было, но обошли пару граблей, т.к. уже имели опыт с сайтом ВСК. На нашем сайте больше однородного контента, поэтому модели для Directus CMS получились удачными. Сейчас Directus CMS позволяет удобно дополнять контент в блоге и кейсах, а также редактировать составляющую других страниц, если требуется поменять текстовое наполнение.

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

Илья Чепайкин

Ведущий frontend-разработчик

У нас неплохой опыт в этом деле, глаз уже наметан, и мы готовы подсказать, где можно оптимизировать проект за счет open-source платформ.  Приходите за советом или приносите идею - проработаем совместно концепцию продукта и реализуем.