Обзор 14 headless cms 2019

Некоторое время назад в одной заметной на российском рынке публичной компании, в которой я работал, встал вопрос об использовании headless cms. Среди множества реализаций нужно было выбрать одну. Это рассказ о том, как я формировал критерии выбора, как анализировал cms-ки, и как этот анализ привел меня к мысли, что нужно писать свою. Обзор 14 headless cms под катом.

Что такое headless CMS?

Хоть термин и не нов, почему-то эта тема в русскоязычном интернете освещена крайне мало. Итак, согласно википедии:

A headless content management system, or headless CMS, is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.
Headless система управления контентом, или headless CMS — это серверная система управления контентом (CMS), которая изначально является хранилищем контента и предоставляет доступ к контенту через RESTful API для отображения на любом девайсе.

Другими словами headless cms — это концепция, этакий специальный тип cms-ок, согласно которой cms отвечает только за управление “чистым” контентом. Это позволяет отделить слой данных, который управляется в cms, от слоя отображения, который управляется клиентским приложением. Контент распространяется в универсальном формате, обычно в JSON, это и дает возможность управлять одновременно веб-сайтом, мобильным приложением и любыми устройствами подключенными к интернету.

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

Погружение в контекст

Чтобы определить критерии поиска и понять, какая headless cms лучше других, мне предстояло ответить на вопрос — лучшая в чем? Какие именно задачи она должна решать и как?

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

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

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

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

• заказчик не должен иметь возможность прострелить себе колено, т.е. контент-менеджер не должен ничего сломать, даже если захочет. Он должен редактировать только то, что предусмотрели разработчики;
• должна быть возможность управлять версиями и откатиться в случае чего;
• неизвестно, какой дополнительный функционал появится в будущем, а это означает, что усложнять или менять раздел должно быть легко;
• со стороны безопасности: система должна быть на нашем сервере, а не в чужом облаке, т.е. должна быть возможность развернуть on-premises.

Хорошо, с задачей все ясно. Перехожу к решению.

Буду использовать Any JSON CMS, это одна из headless cms. Отмечу, что на данный момент она не удовлетворяет всем требованиям описанным выше. Например, контент-менеджер не сможет посмотреть в тестовом окружении, как будут выглядеть правки. Однако, все достоинства и недостатки будут видны позже. Сейчас же я стремлюсь “пощупать” типовой сценарий работы с любой headless cms.

Первое, что нужно сделать — описать модели. Модель отвечает на вопрос, как должна выглядеть контентная сущность? Какая у нее структура? По сути это протокол взаимодействия между cms и клиентским приложением. В нашем случае — обзор к фильму — объект содержит:

• 3 обязательных свойства: название фильма, постер фильма, текст обзора;
• 1 необязательное свойство: объект “режиссер”, который в свою очередь содержит 2 обязательных свойства имя и фамилию.

В виде JSON Schema модель обзора выглядит так:

{
  type: 'object',
  required: ['movieName', 'moviePoster', 'reviewText'],
  additionalProperties: false,
  properties: {
    movieName: {
      type: 'string',
      minLength: 1,
      maxLength: 300,
    },
    moviePoster: {
      type: 'string',
      description: 'URL to file',
    },
    movieProducer: {
      type: 'object',
      required: ['name', 'surname'],
      additionalProperties: false,
      properties: {
        name: { type: 'string', maxLength: 100, minLength: 1 },
        surname: { type: 'string', maxLength: 100, minLength: 1 },
      },
    },
    reviewText: {
      type: 'string',
      minLength: 1,
      maxLength: 3000,
    },
  },
}

Также нужно реализовать feature toggle, модель в виде JSON Schema выглядит так:

{
  type: 'object',
  required: ['isFeatureActive', 'name'],
  additionalProperties: false,
  properties: {
    isFeatureActive: { type: 'boolean' },
    name: { type: 'string', enum: ['movieReviewFeatureToggle'] },
  },
}

Когда есть понимание, как должны выглядеть модели, можно создавать их в Any JSON CMS.



Тут же создаю контентные сущности, т.е. сам контент, на основе моделей. Один фиктивный обзор и feature toggle сущность.



Для интеграции клиентского приложения с cms потребуется API key. Генерирую его в соответствующем разделе cms.


Теперь все готово для реализации функционала в клиентском приложении и интеграции с cms. Клиентское приложение может быть любым — сайт или мобильное приложение, или и то, и другое, написанное на чем угодно. В качестве примера я реализую функционал на сайте SPA на React. По сути мы забираем данные с уже известной, фиксированной структурой из cms и отображаем ее так, как хотим.

import React, { Component } from 'react'
import {
  Accordion,
  AccordionItem,
  AccordionItemTitle,
  AccordionItemBody,
} from 'react-accessible-accordion'

import 'react-accessible-accordion/dist/fancy-example.css'

const apiUrl = 'https://api.anyjsoncms.com'
// ApiKey безопаснее хранить на проксирующем бэкенде
const apiKey = '87414950dfd15648ea560bd89dd0ee02bfc8fcca'

class App extends Component {
  constructor(props) {
    super(props)
    this.state = {
      movies: null,
      isFeatureActive: null,
      loading: true,
    }
  }

  componentDidMount() {
    const options = { method: 'GET', headers: { ApiKey: apiKey } }
    Promise.all([
      fetch(`${apiUrl}/entries?apiId=featureToggle`, options).then(resp =>
        resp.json()
      ),
      fetch(`${apiUrl}/entries?apiId=movieReview`, options).then(resp =>
        resp.json()
      ),
    ])
      .then(([featureToggleResp, movieReviewResp]) => {
        const featureToggle = featureToggleResp.find(
          item => item.value.name === 'movieReviewFeatureToggle'
        )
        const isFeatureActive =
          featureToggle &&
          featureToggle.value &&
          featureToggle.value.isFeatureActive
        const movies = movieReviewResp.map(item => item.value)
        this.setState({ movies, isFeatureActive, loading: false })
      })
      .catch(error => {
        console.error(error)
      })
  }

  render() {
    const { movies, isFeatureActive, loading } = this.state
    if (loading) return <div>Loading...</div>
    if (!isFeatureActive)
      return <div style={{ display: 'none' }}>Section is hidden</div>
    return (
      <div>
        <Accordion>
          {movies.map(
            ({ movieName, moviePoster, movieProducer, reviewText }, index) => (
              <AccordionItem key={index}>
                <AccordionItemTitle>
                  <h3>{movieName}</h3>
                </AccordionItemTitle>
                <AccordionItemBody>
                  <img src={`${apiUrl}${moviePoster}`} alt="" />
                  {!movieProducer ? null : (
                    <div>{`${movieProducer.name} ${
                      movieProducer.surname
                    }`}</div>
                  )}
                  <div>{reviewText}</div>
                </AccordionItemBody>
              </AccordionItem>
            )
          )}
        </Accordion>
      </div>
    )
  }
}

export default App

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

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

Критерии выбора и анализ headless cms

После того, как у меня появилось понимание, какие задачи будут решаться при помощи headless cms и как именно, я выделил критерии и начал изучать системы. Сейчас согласно сайту headlesscms.org существует 54 cms. Проанализировать их все — довольно трудоемкий процесс, поэтому я выделил 14 наиболее популярных, заметных и обсуждаемых систем: Any JSON CMS, Contentful, Strapi, GraphCMS, Squidex, Butter CMS, Cloud CMS, Сockpit, Cosmic JS, Directus, Kentico Cloud, Netlify CMS, Prismic, Ghost.

Результаты удобнее изучать в виде таблицы. Но продублирую и здесь.

Any JSON CMS

Contentful

Strapi

GraphCMS

Squidex

Butter cms

Cloud CMS

Сockpit

Cosmic JS

Directus

Kentico Cloud

Netlify CMS

Prismic

Ghost

Выводы

По большому счёту от headless cms я ожидал увидеть две основные вещи: свободу в создании моделей, благодаря чему можно реализовать любой протокол, и git подобную систему контроля версий, чтобы можно было прозрачно управлять всеми изменениями.
И меня ждало легкое разочарование. Хотя с большинством из этих систем можно работать, они обладают рядом неприятных для меня недостатков. Это, конечно, не значит, что системы плохие, это лишь означает, что они не удовлетворили мои ожидания, а мои ожидания — это мои проблемы. Озвучу их:

• Большинство headless cms поддерживают вложенные структуры данных только через ссылки. Если нужен объект, внутри которого другой объект, то придется создавать две отдельные модели и связывать их через ссылку. Этот принцип оправдан, когда вложенный объект переиспользуется, но если нет, то в системе просто появляется лишняя модель, а за ней и лишние контентные сущности. Такой подход со временем заметно увеличивает и количество моделей, и количество контентных сущностей, что ведет к путанице. Плюс-минус полноценно вложенность поддерживается только в Cloud CMS, Cockpit и Cosmic JS.
• Иногда требуется комбинировать типы данных: нужно, чтобы свойство объекта было или строкой, или числом. Ну хорошо, в этой ситуации еще можно что-нибудь придумать, в зависимости от конкретного кейса — добавить валидацию при помощи регулярного выражения и нормализовать данные на клиенте. Но что делать, если нужно скомбинировать что-то посложнее, например так:
  

  {
    "oneOf": [
      { "type": "number", "multipleOf": 5 },
      { "type": "number", "multipleOf": 3 }
    ]
  }
  

  
  Комбинировать типы данных умеет только Cockpit.
  
• Хотелось, чтобы система оповещала о конфликтах между моделью и контентными сущностями. Например, есть модель типа number, у этой модели есть контентная сущность со значением 100. Что произойдет если изменить модель, добавив туда валидацию maximum: 50? Оповестит ли система о конфликте? Такой функционал качественно реализует только GraphCMS.
• Git подобную систему контроля версий поддерживают только Cloud CMS и Netlify CMS.

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

Заключение

Вот так этот анализ и привел меня к мысли, что нужно писать свою headless cms. Вы ее уже видели, на ее примере была демонстрация решения задачи. Она называется Any JSON CMS.

UPDATE: Any JSON CMS стала open source решением, репозиторий на github здесь.

Основная ее цель — предоставить свободу в создании сколь угодно сложных моделей и контролировать все изменения при помощи git подобной системы. Сейчас реализовано далеко не все, что хотелось бы, он основной “посыл” уже есть.