Подскажите такой паттерн проектирования, когда вся конфигурация представляется в виде единого дерева



Подскажите пожалуйста про такой паттерн проектирования, когда вся конфигурация / состояние системы представляется в виде единого дерева.

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

Т.е. у нас нет отдельного апи вида «создай такой стрим». Есть апи вида: «накати такой 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 {....}

Вопрос: это какой-то хорошо известный паттерн? Наверняка же кто-то подобным образом проектирует системы?

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

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

168   17  
  1. Дмитрий Поляков 3 месяца назад
    У нас что-то подобное было до эпохи терраформа-большие json-сценарии описания инфры (10-15к строк). Из-за размера и вложенности, очень сложно было с ними работать.
  2. Vitalii Skakun 3 месяца назад
    хм напоминает декларативное программирование
    например у терраформ похоже (насколько я понял) реализовано

    апд - похоже но не совсем
    там есть сохраненный стейт (дефолт в джейсоне локально в файле) и конфиг

    по отличиям между ними, чтоб привести стейт в соответствие конфигу, тф как раз и гоняет кучу "нелепых мелких запросов" к (сервис)провайдеру
  3. Ilya Golshtein 3 месяца назад
    Примерно такими дорогами ходят люди, использующие GraphQL.
  4. Михаил Кузьмин 3 месяца назад
    Есть datomic.com.
    Это БД для хранения данных в виде [id attribute value].
    Так можно представить и дерево и граф.

    Еще плюс, данные можно отображать в виде вложенных документов, см pull api.
    Можно писать в виде вложенных документов.

    Изменения там описываются данными, можно провести некую аналогию с вашими патчами.
    Можно делать разные запросы, в том числе рекурсивные. Так получится делать срезы для REST.
    Можно там и другие данные хранить.

    Есть https://github.com/tonsky/datascript это "БД" c сходными принципами, открытая, бесплатная, без персистентности и кроме clojure/java есть js api.
  5. Григорий Кочанов 3 месяца назад
    "создай стрим, создай урл для такого-то стрима, создай транскодер для стрима" - это не REST, а RPC, потому что это не передача состояния объекта с клиента на сервер, а команды.
    То, что вы сделали - это вы приводите состояние на сервере, чтобы оно было репрезентативно состоянию на клиенте. Это RESTful api :)
  6. Алексей Кудряшов 3 месяца назад
    1. положить дерево в монгу и делать запросы через mongo query, через парзер. сами запросы слушать на эндпоинте, парзить и отправлять в монгу. это обслуживаемо и универсально. можно писать агрегаты и прочее и использовать всю мощь mongo-query. 2. graphql, но там буков много надо писать. 3. endpoint selector json path mutate/read. В любом случае, вначале надо решить задачу указания пути в дереве (выбрать язык), затем задачу выполнения этого запроса. Я бы наверное взял первый вариант, как собираемый практически без кода на коленке. Вся утилитарная часть будет на монге.
  7. Sergei Bashakov 3 месяца назад
    Как-то ты цели нечетко описал. Ну дерево у тебя, хорошо. Прикол в том, что при некоторой ловкости и допущениях любую систему можно развернуть в виде дерева. Даже паттерн composite придумали.
  8. Сергей Аксёнов 3 месяца назад
    http://jsonpatch.com/
  9. Giorgi Kutsu 3 месяца назад
    Видел что-то похожее в terraform и том как они хранят состояние, тут выше написали. Еще можно поглядеть, например, на LSM-Tree тип деревьев, по идее должна хорошо лечь, но в сравнении с B-Tree, чтение будет медленнее, зависит от вашего юз кейса. Вот например LSM-Tree KV строадж https://github.com/dgraph-io/badger
  10. Yu Ersh 3 месяца назад
    Посмотрите https://jsonnet.org/
  11. Сергей Арбузов 3 месяца назад
    Похоже на netconf/restconf
  12. Алексей Кудряшов 3 месяца назад
    Еще у нового реакта появился recoil.js для работы с комплексным стейтом, можно там идеи посмотреть
  13. Paul Tru 3 месяца назад
    У меня на проекте очень похоже сейчас, только есть все таки прослойка которая контролирует патчи на предмет валидности, авторизации и прочего.

    Json-schema уже прикрутили или ещё впереди?

    ПС я не оч разбираюсь но вроде графКьюЭл про что-то такое как раз.
  14. Alexey Rybak 3 месяца назад
    В Badoo была похожая система для конфигураций серверов и ядреного ПО, мб до сих пор так. Andrei Nigmatulin делал, все упаковывалось в пути на фс площадка/группа-хостов/сервисы или площадка/группа-хостов/конкретная-машина/сервисы.
  15. Alexey Rybak 3 месяца назад
    Вряд ли у этого есть какое-то имя, главное чтобы смысл паковки конфигурации был строго ориентирован сверху вниз и был четкий алгоритм «наследования» и «переопределения».
  16. Nicola Ryzhikov 3 месяца назад
    Ты уверен что это прям дерево а не набор аггрегатов?
  17. Антон Герасимов 3 месяца назад
    Макс Лапшин: в своём посте ты пишешь, что операции в API приходят как некий патч с некоторыми операциями.

    А является ли этот батч атомарным и как решать вопросы возврата ошибок в случае, если:
    По середине что-то пошло не так, а дальше нормально?
    Клиент использует разный контекст операции внутри одного патча?

    На мой взгляд, введение стейта в API -- не самая хорошая практика.

    Так же хотелось понять -- зачем такое усложнение в API?

Добавить ответ:
Отменить.