Спецификация переносимых модулей администрирования
Разрабатываем общий способ подключать сервисы и микросервисы к одной панели управления с едиными правилами доступа, разделения данных клиентов и аудита действий.
Узнать об идееСпецификация в разработке · Черновик 0.1.0
ЧТО МЫ СОЗДАЁМ
OpenAdminSpec — спецификация для единой админки сервисов и микросервисов. Она задаёт общий формат, в котором сервис описывает свои экраны, операции и требования к доступу, а совместимая платформа собирает из этих модулей рабочий интерфейс.
Наша цель — чтобы каждый новый сервис не требовал ещё одной отдельной админки. Команды сохраняют свои API, данные и бизнес-логику, а сотрудники работают с ними в общей панели: с понятными правами, выбором клиента или проекта и историей действий.
КАК ЭТО УСТРОЕНО
Разработчики готовят описание API, доступных операций, прав и экранов. Модуль связывает поля форм и таблиц с данными сервиса и указывает, какое действие вызывается при нажатии кнопки.
Платформа проверяет описание и поддержку нужных возможностей. Оператор выбирает конкретную версию, подтверждает адрес сервиса, настраивает учётные данные и выдаёт права.
Совместимая панель собирает описанные экраны. При каждом действии её сервер проверяет доступ и выбранный проект, обращается к API сервиса и показывает результат. Сам сервис также проверяет права и выполняет бизнес-правила.
ЧТО ВХОДИТ В КОНТРАКТ
OpenAPI описывает запросы, JSON Schema — структуру данных. Переносимое описание интерфейса связывает таблицы, формы и карточки с этими данными. Команда может использовать разные библиотеки интерфейса, сохраняя смысл полей, проверок и команд.
Вход сотрудника в панель и доступ платформы к API сервиса — отдельные задачи. Для каждой операции указываются способ аутентификации и необходимое право. Секреты хранятся на сервере, а права проверяются при каждом запросе.
Один модуль можно подключить несколько раз, с разными адресами, настройками и правами. Проект задаёт область данных, например отдельного клиента. Доступ проверяется для выбранного подключения и проекта; сервисам без такого разделения проекты не требуются.
Черновик описывает обычные запросы, запуск длительных задач, получение их состояния и результатов. Для файлов предусмотрены правила загрузки, скачивания и привязки к записям. Выполнение задач и доступ к файлам остаются частью работы сервиса.
Новая версия проходит проверку и отдельное одобрение для выбранного подключения. Уже принятое описание сохраняется неизменным. Перед активацией платформа проверяет поддержку необходимых возможностей.
Общий формат аудита связывает операцию с её инициатором, подключением, проектом и результатом. Так можно разобраться, кто запустил изменение и что произошло, даже если запрос к API был выполнен от имени самой платформы.
НАПРИМЕР
Представьте продукт с отдельными сервисами учётных записей, счетов и публикаций. Сотрудник поддержки мог бы найти клиента, финансист — проверить его счета, а редактор — обновить материалы нужного проекта. Каждый работал бы с разрешёнными ему данными и действиями через общую панель.
Для команд это означало бы меньше повторной работы над подключением и интерфейсами. Сервисы по-прежнему отвечали бы за свои API и бизнес-правила. Спецификация делает интеграцию предсказуемее; описание модуля, настройку подключения и проверку совместимости всё равно нужно выполнить.
В РАЗРАБОТКЕ
Спецификация пока находится на стадии черновика и продолжает развиваться. Полный сайт скоро появится.