Focus: Как мы собрали конструктор админок для SOA

Привет! Меня зовут Миша Дадаев, я techlead в провайдере e-com & data решений АЭРО. Недавно мы разработали low-code систему (CMS) для управления контентом на сайте с сервисной архитектурой. Как это было и зачем нужно — расскажу в этой статье.

Сегодня большинство наших заказчиков уже перешли на сервисную архитектуру. С сервисным подходом уже давно знакомо большинство разработчиков — на собеседовании любой выпускник вуза с легкостью объяснит вам, что значит паттерн database per service и почему это хорошо. В реальной жизни мы сталкиваемся не только с разработкой, но и эксплуатацией проектов, где одной из важных задач является управление данными внутри сервисов.

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

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

• Мы хотим разделить существующий монолитный проект с действующей админ-панелью, которая не работает с отдельными сервисами;
• Мы хотим разработать MVP сразу на сервисной архитектуре, но не хотим тратить много времени на разработку собственной админки

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

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

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

Конечно, не хотелось изобретать велосипед, и мы провели небольшой ресерч уже существующих open-source решений, выделили их плюсы и минусы. Так, готовые решения содержат понятную документацию, хороший технологический стек, широкий выбор готового функционала и распространены среди большого комьюнити. Однако часть функционала доступна только в платной версии, решения заточены только под определенный фреймворк, и их нельзя объединять с собственными backend-ами, а некоторые админки уже и вовсе не поддерживаются.

Почему же в открытых источниках не найти множество готовых бесплатных решений, подходящих под наши требования? Причин может быть сразу несколько:

• Разрабатывать админки не так интересно как, например, собственные поисковые движки или собственные базы данных;
• У крупных продуктов есть свои наработки, но они не очень хотят ими делиться с общественностью;
• Когда мы хотим сократить бюджет, удобное управление контентом — это первое чем мы пожертвуем;
• На многих продуктах есть свои решения, но их нельзя использовать на других продуктах, так как они спроектированы под конкретный проект.

Мы понимали, что будет сложно соревноваться по функционалу с такими известными на всю индустрию решениями для админ-панели как Bitrix, Wordpress, Tilda, Django admin, Strapi и другими. Поэтому было решено реализовать admin-фреймворк с минимальным функционалом для MVP, который можно будет быстро расширять и адаптировать под нужды любого проекта.

Для последующей разработки мы сформировали ряд принципиально важных критериев, которым должен был отвечать Focus Admin:

• CMS совместима с сервисной архитектурой сайта;
• Части backend и frontend независимы друг от друга и заменяемы;
• Единая точка управления всеми сервисами сосредоточена в одном интерфейсе;
• Админка поддерживает различные языки программирования и базы данных;
• CMS содержит универсальные плагины для решения типовых задач бизнеса;
• Гибкость: возможно кастомизировать админку и расширять функционал под каждый отдельный проект.

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

Бэклог уходит далеко за рамки этого списка, но для MVP этого будет достаточно.

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

focus-плагины. Это пакеты, которые можно установить на backend-сервисы. Когда на сервис устанавливается плагин, он добавляет к публичному API сервиса готовое API, поддерживающее запросы от frontend.

admin-connector. Данный сервис отвечает за подключение backend-сервисов к admin-панели. Чтобы сервис и установленные плагины отображались в интерфейсе, их нужно зарегистрировать в настройках admin-connector (указать адрес, отображаемое название, установленные модули и т.д.). Также admin-connector проверяет наличие доступа на совершение запросов и проксирует запросы от frontend к нужному backend-сервису.

Важным моментом является то, что Focus не имеет собственной базы данных и сам ничего не хранит в себе. Все данные, которыми он управляет расположены в backend-сервисах.

Веб-интерфейс

В коробочной версии frontend мы использовали UI-библиотеку, чтобы не верстать с нуля все элементы интерфейса, а использовать готовые компоненты на react. Frontend и backend проекта полностью независимы друг от друга: frontend не завязан на определенный набор сервисов, а в контракте с backend (спецификации) есть лишь описание API плагина, при этом каждый плагин может быть установлен на любое количество серверов. При добавлении новых сервисов не нужно править код пользовательского интерфейса.

Переключение между сервисами

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

Принцип работы довольно прост: frontend передает код нужного сервиса, а на стороне backend реализован api-gateway (в нашей системе он называется admin-connector), который выступает в роли роутера админских запросов к сервисам.

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

Плагины

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

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

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

low code

Время разработки — это деньги. Поэтому одним из самых важных требований является минимизация временных затрат разработчика при расширении функционала админ-панели. Поскольку Focus является low-code системой, на наполнение сайта и изменение контента уходит мало времени.

Универсальное API

Разберемся на примере плагина медиабиблиотеки. Представьте, что у нас есть 2 сервиса: Каталог и Контент. Для каждого из них требуется собственная медиабиблиотека. В каталоге мы будем хранить изображения товаров и категорий, в контенте — изображения для баннеров и слайдеров. Чтобы не писать под каждый новый сервис собственную библиотеку, можно построить API для абсолютно одинаковой работы двух сервисов с медиабиблиотекой.

Конструктор для сущностей

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

Конструктор контентных блоков (сниппеты)

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

Для корректной и безопасной работы административная панель должна быть закрыта от внешнего мира авторизацией. Также должны быть предусмотрены различные права доступов для разных ролей пользователя. Для авторизации мы взяли готовый инструмент keycloak, в котором есть возможность настройки ролей и прав. Для доступа к функционалу админ-панели используется jwt-токен, который проверяется на уровне api-gateway (admin-connector). Для неавторизованных пользователей cms не доступна. Более детальное описание процесса настройки интеграции Focus и keycloak доступно в документации.

После выполнения действий, описанных в инструкции, можно задавать следующие ограницения доступов:

• Пользователю доступны все плагины только в сервисе контента;
• Пользователю доступен только плагин конфигурации в сервисах контента и каталога;
• Пользователю доступно чтение информации в модели акции в сервисе каталога
• и т.д.

Во второй части я расскажу о работе CMS Focus на примере с конкретными сервисами.