Подскажите такой паттерн проектирования, когда вся конфигурация представляется в виде единого дерева
Подскажите пожалуйста про такой паттерн проектирования, когда вся конфигурация / состояние системы представляется в виде единого дерева.
У нас в флюссонике сама собой родилась и развилась следующая конструкция, которая достаточно удобно рендерится реактом и используется внутри самого сервера: вся конфигурация сервера (а это может быть, например до десятков тысяч значений) представима в виде большого дерева глубокой вложенности.
Т.е. у нас нет отдельного апи вида «создай такой стрим». Есть апи вида: «накати такой JSON-патч на конфигурацию» и в этом патче как раз будет удаление одного стрима, создание другого, правка третьего.
Такая структура получается ортогональна ресту, но она очень удобна, потому как в противном случае надо бы гонять сотни мелких нелепых запросов вида:
* создай стрим * создай урл для такого-то стрима * создай транскодер для такого-то стрима * создай выходной трек для транскодера такого-то стрима
(возможно и другое проектирование конечно).
Вместо этого отправляется одним батчем запрос на создание стрима с транскодером и т.п.
Для того, чтобы это удобно работало, мы почти полностью отказались от списков в этом конфиге, всё представляется в виде глубоко вложенных объектов. Так, например, список стримов — это объект у которого ключи — имена потоков, а позиция в списке — поле position у каждого.
Дальнейшие операции достаточно просты и логичны, потому как сам патч к такому конфигу имеет точно такой же (почти) синтаксис, как и сам конфиг. Удаление ветки в таком дереве — проставление значения null / undefined.
Следующий шаг у нас — приделать ко всему этому какой-то полуавтоматизированный способ сделать всё таки REST API, который будет отдавать определенные слои и ветки этого дерева:
GET /streams GET /streams/ort GET /streams/ort/transcoder DELETE /streams/ort/urls/0 POST /streams/ort/push/5 {....}
Вопрос: это какой-то хорошо известный паттерн? Наверняка же кто-то подобным образом проектирует системы?
Хочется посмотреть, как с такой концепцией люди живут, в частности, как заказывают глубину получения дерева или отдельные поля.
Второй вопрос, который конечно специфичен для нас, но всё же: если почти всё в таком дереве, то надо уже вообще все данные туда засовывать, или это некоторый перебор и какие-то куски имеет смысл держать отдельно.
например у терраформ похоже (насколько я понял) реализовано
апд - похоже но не совсем
там есть сохраненный стейт (дефолт в джейсоне локально в файле) и конфиг
по отличиям между ними, чтоб привести стейт в соответствие конфигу, тф как раз и гоняет кучу "нелепых мелких запросов" к (сервис)провайдеру
Это БД для хранения данных в виде [id attribute value].
Так можно представить и дерево и граф.
Еще плюс, данные можно отображать в виде вложенных документов, см pull api.
Можно писать в виде вложенных документов.
Изменения там описываются данными, можно провести некую аналогию с вашими патчами.
Можно делать разные запросы, в том числе рекурсивные. Так получится делать срезы для REST.
Можно там и другие данные хранить.
Есть https://github.com/tonsky/datascript это "БД" c сходными принципами, открытая, бесплатная, без персистентности и кроме clojure/java есть js api.
То, что вы сделали - это вы приводите состояние на сервере, чтобы оно было репрезентативно состоянию на клиенте. Это RESTful api :)
Json-schema уже прикрутили или ещё впереди?
ПС я не оч разбираюсь но вроде графКьюЭл про что-то такое как раз.
А является ли этот батч атомарным и как решать вопросы возврата ошибок в случае, если:
По середине что-то пошло не так, а дальше нормально?
Клиент использует разный контекст операции внутри одного патча?
На мой взгляд, введение стейта в API -- не самая хорошая практика.
Так же хотелось понять -- зачем такое усложнение в API?