CMS на Node.JS - обзор 11 систем простыми словами

В прошлых статьях я писал, что наша студия специализируется на разработке мобильных приложений и сложных веб проектов для стартапов и что мы ушли от Битрикса в сторону Node. JS. Сегодня я продолжу тему и сделаю обзор на 11 разных CMS для Node с комментариями в первую очередь для основателей стартапов.

Вот предыдущая статья про уход с Битрикса, если интересны причины:

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

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

Нельзя было не обратить внимания на то, какой CMS-ки закрывали пласт задач: были ли это просто headless-системы, помогающие лишь сгенерировать API, или же полноценные админки с веб-интерфейсом и пр. И с какими базами данных они работают (есть, кстати, админки, которые вообще работают без БД, используя чисто текстовые файлы).

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

Составил предварительный список из 11 CMS для предварительного изучения и те, которые прошли в шорт-лист были детально разобраны техдиром. Итак:

У Keystone есть админка для управления контентом, но создание моделей идёт в файлах при помощи конфига. Шаблонизатора нет. Возможно использование GraphQL. Система бесплатная, есть интерфейс админки и, соответственно, возможность разработки самого бэкенда. Использует реляционные базы данных типа Postgres, SQL и SQLite. Аутентификация пользователей имеется, оплату нужно прикручивать.

Что не понравилось: маленькое сообщество, а значит, достаточно медленное развитие. Слишком бедный выбор модулей от сторонних разработчиков.

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

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

Система бесплатная, есть интерфейс админки и возможность разработки бэкенда, база есть, но только MongoDB. Аутентификация пользователей имеется, оплату нужно прикручивать.

Что не понравилось: написано на VUE, нет особой гибкости, маленькая документационная база и скромное сообщество.

Представляет собой не чисто Node. JS-админку, а некий «клон» Вордпресса, который можно использовать как headless. Из-за чего даже не стали копать глубже, как только об этом узнали, так как подобный вариант нам не подходит. Cистема бесплатная, но её использование требует хостинга у разработчика, а это уже платно. Интерфейс админки и разработка бэкенда есть, база данных – MySQL 8, все возможности – как у WP.

Что не понравилось (кроме идентичности с WP): нет большого количества плагинов. Сообщество тоже маленькое. Для того же блогерского проекта проще выбрать PHP-админку: смысла заморачиваться с Node. js, по-моему, нет.

Есть админка для создания контента, есть – для создания моделей; последние делаются как через файлы, так и через админку. Фронтенд подключается через сгенерированный API. Strapi бесплатна (с возможностью платного размещения на хостинге разработчика и оплаты за дополнительных админов), в качестве БД используются MySQL, MariaDB, Postgres, SQLite.

Что не понравилось: серьёзных претензий к системе нет: можно придраться по мелочам, но в общем и частном всё работает хорошо.

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

Что не понравилось: явно не наш вариант.

Есть админка для создания контента, модели создаются в файлах; админка с урезанным функционалом – бесплатная, имеются тарифы для бизнеса и команды с дополнительными модулями. К БД доступа нет, всё работает на хостинге команды разработки.

Совсем как в случае с Firebase: работать с базой можно, делать свои скрипты и обращаться к ним, но залить на свой сервак нельзя. Если это не смущает и подходит под ваши цели – всё ок, проблем быть не должно.

Что не понравилось: Выше упомянутое отсутствие доступа к БД, имеется только GraphQL API. Классического REST для небольшого или слабонагруженного проекта, увы, нет.

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

Что не понравилось: невозможность работы с базой и собственный хостинг системы.

Больше похоже на конструктор или даже на гутенбрег-тему для Wordpress: прямо такая классическая надстройка на WP для Node. js. Есть API, заточенное под Next. js, есть компоненты, которые пишутся на React. Есть неплохой бесплатный тарифный план, есть платные расширениями. Есть интерфейс админки и возможность предпосмотра контента – в общем, всё то, что тянется из Wordpress.

Что не понравилось: не можем работать с базой данных, хостинг заточен на Next и Nuxt.

Ещё один «гутенберг», использует только GrapQL. Система полностью бесплатна, есть интерфейс админки, возможность предпосмотра; базы нет, работа – на md-файлах.

Что не понравилось: аналогично, не можем работать с базой данных, хостинг заточен на Next.

Есть админка для создания контента, модели создаются в файлах. Админка платная для развёртывания. Есть интерфейс панели администратора. Базы данных и доступа к ней опять нет.

Что не понравилось: Нет доступа к БД. К тому же, заточена под React (у нас всё на Angular).

Есть админка для создания контента, есть – для создания моделей. Последние можно также делать в файлах, шаблонизатора, соответственно, нету. На своём серваке система бесплатна, на хостинге разработчика – за деньги. Есть интерфейс админки, модели создавать прямо непосредственно в ней. База есть, используются MySQL, MariaDB, Postgres, SQLite. Под наши задачи подходит.

Как и у Страпи, никаких особых косяков не нашли, поэтому всё устраивает.

Если отсеять конструкторы и системы без БД, то админки у CMS достаточно похожи друг на друга: что, впрочем, и неудивительно, поскольку делались они для решения примерно одинаковых задач. Мы для себя выделили Keystone, Strapi, Sanity и Directus. В приоритете – Strapi, ввиду внушительного сообщества и большого количества модулей.

Теперь – более подробно о четырёх кандидатах.

Нас интересуют следующие вопросы:

Установка в принципе не сложная, билдится в обычную статику. Доступа к базе у Санти нет, так что особого смысла ставить её у себя нет тоже. Вне зависимости от выбранного варианта потребуется наличие собственного аккаунта в системе – что и стало для нас стоп-сигналом.

Жёсткая привязка к разработчику системы, разворачиваем ли мы на своём серваке или на облаке Santi, которая в какой-то момент времени вообще может стать платной или недоступной для российских разработчиков – большой минус.

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

Интерфейс Santi

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

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

Коллекции создаются в админке (но только в режиме разработки). Можно разворачивать в режиме разработки на сервере; если человек, который занимается разработкой и администрированием – это одно лицо, система работает в dev-режиме, и постоянно перекидывать в продакшн не требуется.

API понятное, но при большой вложенности свойства в самой админке не видны. Хотя и это можно пофиксить определёнными параметрами в запросе. Можно работать как с классическим Rest API, так и с GraphQL, причём второй подключается плагином.

Интерфейс Strapi

Выглядит админка у Strapi чуточку пободрее. Слева в меню есть вкладка «Content manager», непосредственно управление контентом.

Вкладка «Content-Type Builder» отвечает за управление сущностями: те самые три поля, которые мы видели в туду-листе. Сущность редактируется, доступно полное управление списком: можно добавить любой тип поля (присутствуют подсказки, для чего они нужны).

«Media Library» – всё то, что мы загрузили: перечень файлов, плагинов, маркетплейс плагинов, которые можно выбрать и установить прямо с админки.

Ну и «Settings»: здесь есть админская роль, роль редактора, управление доступа, пользователи. В принципе, Strapi платная только за счёт количества админов, плюс берут деньги за техподдержку и за дополнительные платные модули.

Как я уже писал, установить у себя на сервере её нельзя, можно работать только в облаке. Вся установка, работа с контентом и создание моделей сложностей не вызвали, всё работает, как и должно. Можно использовать как классический Rest, так и поставить модуль для GraphQL. Коллекции создаются в админке, к файлам доступа у нас нет.

Частично Directus по возможностям похож на Strapi; API, которое отдаёт на фронт удобнее, но возникает большая проблема для российских клиентов, поскольку все серваки расположены в облаке: для хранения персональных данных придётся делать какую-то дополнительную надстройку. При прочих равных смысла в этом нет. Система платная, оплатить с российских карт нельзя, надо заводить зарубежную, что стало дополнительным минусом Directus.

Интерфейс Directus

Как и у Strapi, в самом верху находится меню управления контентом. Мы можем редактировать, добавлять что-то новое, изменять поля. Отображаются все модели, которые мы создадим; классическая возможность создания/редактирования – как и у Страпи, разделы очень похожи. В админке, по необходимости, можно по тем или иным параметрам создать фильтр.

Следующее – управление пользователями, отдельно обычными, отдельно – админами.

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

Затем – документация для разработчика и базовые настройки, где создаются модели данных.

Кроме наличия статистки понравился более богатый, чем у Strapi, выбор полей с визуализацией их примерного размещения. И управление ролями, в которых настраивается доступ на типовые действия для разных групп пользователей: есть и в Страпи, но здесь поудобнее. Если бы не облачная история, Directus очень бы подошёл, но – увы!

Из всех четырёх вариантов система оказалась самой слабой. Да ещё и с проблемной установкой: не получилось поставить даже с пятой попыткой, пришлось гуглить, что не так. Оказалось, проблема в докерфайле, который ругался на отсутствие папки, которая на самом деле есть. Как это вылечить, быстро не нашли, поэтому попросту забили: если система вызывает проблемы ещё на этапе установки, это что же будет потом? Верю что дело не в админке, а в наших кривых руках, но се ля ви.

Из трёх последних кандидатов мы остановились на Strapi ввиду целой совокупности позитивных факторов:

Позже, когда мы познакомились со Strapi поближе, мы обнаружили ещё несколько любопытных моментов.

Single-контент

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

Много типов полей

Это очень удобно, не нужно выдумывать и описывать то, что уже есть.

Есть возможность локализации

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

Есть связки между коллекциями

Аналог SQL Join: выборку из соседней коллекции можно запросить и разместить в собственной коллекции.

Возможность создания динамических полей

Про этот пункт я, пожалуй, напишу отдельную статью: уж слишком много здесь всего придётся рассматривать. Но если в двух словах, то в зависимости от ситуации здесь можно изменять тип поля у объекта.

Итак, мы выбрали Strapi. В ближайшее время расскажу, как мы планируем развивать на этой админке наше готовое решение для маркетплейсов услуг, и как мы будем выстраивать логику и архитектуру в зависимости от системы на Node. js.