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



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

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

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

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

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

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

858   17  

Comments

  1. Дмитрий Поляков
    Дмитрий Поляков 5 лет назад
    У нас что-то подобное было до эпохи терраформа-большие json-сценарии описания инфры (10-15к строк). Из-за размера и вложенности, очень сложно было с ними работать.
  2. Vitalii Skakun
    Vitalii Skakun 5 лет назад
    хм напоминает декларативное программирование<br>например у терраформ похоже (насколько я понял) реализовано<br><br>апд - похоже но не совсем<br>там есть сохраненный стейт (дефолт в джейсоне локально в файле) и конфиг<br><br>по отличиям между ними, чтоб привести стейт в соответствие конфигу, тф как раз и гоняет кучу "нелепых мелких запросов" к (сервис)провайдеру
  3. Ilya Golshtein
    Ilya Golshtein 5 лет назад
    Примерно такими дорогами ходят люди, использующие GraphQL.
  4. Михаил Кузьмин
    Михаил Кузьмин 5 лет назад
    Есть datomic.com.<br>Это БД для хранения данных в виде [id attribute value].<br>Так можно представить и дерево и граф.<br><br>Еще плюс, данные можно отображать в виде вложенных документов, см pull api.<br>Можно писать в виде вложенных документов.<br><br>Изменения там описываются данными, можно провести некую аналогию с вашими патчами.<br>Можно делать разные запросы, в том числе рекурсивные. Так получится делать срезы для REST.<br>Можно там и другие данные хранить.<br><br>Есть https://github.com/tonsky/datascript это "БД" c сходными принципами, открытая, бесплатная, без персистентности и кроме clojure/java есть js api.
  5. Григорий Кочанов
    Григорий Кочанов 5 лет назад
    "создай стрим, создай урл для такого-то стрима, создай транскодер для стрима" - это не REST, а RPC, потому что это не передача состояния объекта с клиента на сервер, а команды.<br>То, что вы сделали - это вы приводите состояние на сервере, чтобы оно было репрезентативно состоянию на клиенте. Это RESTful api :)
  6. Алексей Кудряшов
    Алексей Кудряшов 5 лет назад
    1. положить дерево в монгу и делать запросы через mongo query, через парзер. сами запросы слушать на эндпоинте, парзить и отправлять в монгу. это обслуживаемо и универсально. можно писать агрегаты и прочее и использовать всю мощь mongo-query. 2. graphql, но там буков много надо писать. 3. endpoint selector json path mutate/read. В любом случае, вначале надо решить задачу указания пути в дереве (выбрать язык), затем задачу выполнения этого запроса. Я бы наверное взял первый вариант, как собираемый практически без кода на коленке. Вся утилитарная часть будет на монге.
  7. Sergei Bashakov
    Sergei Bashakov 5 лет назад
    Как-то ты цели нечетко описал. Ну дерево у тебя, хорошо. Прикол в том, что при некоторой ловкости и допущениях любую систему можно развернуть в виде дерева. Даже паттерн composite придумали.
  8. Сергей Аксёнов
    Сергей Аксёнов 5 лет назад
    http://jsonpatch.com/
  9. Giorgi Kutsu
    Giorgi Kutsu 5 лет назад
    Видел что-то похожее в terraform и том как они хранят состояние, тут выше написали. Еще можно поглядеть, например, на LSM-Tree тип деревьев, по идее должна хорошо лечь, но в сравнении с B-Tree, чтение будет медленнее, зависит от вашего юз кейса. Вот например LSM-Tree KV строадж https://github.com/dgraph-io/badger
  10. Yu Ersh
    Yu Ersh 5 лет назад
    Посмотрите https://jsonnet.org/
  11. Сергей Арбузов
    Сергей Арбузов 5 лет назад
    Похоже на netconf/restconf
  12. Алексей Кудряшов
    Алексей Кудряшов 5 лет назад
    Еще у нового реакта появился recoil.js для работы с комплексным стейтом, можно там идеи посмотреть
  13. Paul Tru
    Paul Tru 5 лет назад
    У меня на проекте очень похоже сейчас, только есть все таки прослойка которая контролирует патчи на предмет валидности, авторизации и прочего.<br><br>Json-schema уже прикрутили или ещё впереди? <br><br>ПС я не оч разбираюсь но вроде графКьюЭл про что-то такое как раз.
  14. Alexey Rybak
    Alexey Rybak 5 лет назад
    В Badoo была похожая система для конфигураций серверов и ядреного ПО, мб до сих пор так. Andrei Nigmatulin делал, все упаковывалось в пути на фс площадка/группа-хостов/сервисы или площадка/группа-хостов/конкретная-машина/сервисы.
  15. Alexey Rybak
    Alexey Rybak 5 лет назад
    Вряд ли у этого есть какое-то имя, главное чтобы смысл паковки конфигурации был строго ориентирован сверху вниз и был четкий алгоритм «наследования» и «переопределения».
  16. Nicola Ryzhikov
    Nicola Ryzhikov 5 лет назад
    Ты уверен что это прям дерево а не набор аггрегатов?
  17. Антон Герасимов
    Антон Герасимов 5 лет назад
    Макс Лапшин: в своём посте ты пишешь, что операции в API приходят как некий патч с некоторыми операциями.<br><br>А является ли этот батч атомарным и как решать вопросы возврата ошибок в случае, если:<br>По середине что-то пошло не так, а дальше нормально?<br>Клиент использует разный контекст операции внутри одного патча?<br><br>На мой взгляд, введение стейта в API -- не самая хорошая практика.<br><br>Так же хотелось понять -- зачем такое усложнение в API?