Мы достаточно шустрый RBAC у себя запилили для GraphQL. Пришлось голову сильно поломать.

К примеру “волосатый” GraphQL-запрос может быть равносилен 100 REST запросам. Что потребует 100 обращений к RBAC сервису.

В итоге RBAC как отдельный микросервис не канает. Он должен быть прям на машине где выполняется GraphQL.

В двух словах сделали так: перед выполнением запроса для текущего пользователя тянутся все политики и правила с базы одним запросом. Далее все 100 проверок осуществляются уже враперами резолверов с проверкой правил из памяти.

Вобщем видимо про эту тему надо будет доклад запилить.

я имел ввиду рест апи всегда дергаться будет

ладно всем спасибо, пойду говнокодить

так а в чем проблема ?

const restResponse = api.get('...')

let localFromMongodb = {}  
if (fileds.includes('field1') {
  localFromMongodb = localservice.get() 
}

return merge(restResponse, localFromMongodb)

филды с квери таким образом можно достать

К слову, я чекаю info в ризовлере, чтобы получить projection твоего квери и дальше исходя из того, есть ли определённые филды в квери, дёргаю эндпоинты

спс

👌

Сегодня заюзал монговские транзакции с Decimal128 для бабла. Прекрасно работают. В mongoose даже есть встроенные повтор транзакций, когда юзаешь session.withTransaction(() => { …code … }). К примеру, если баланс поменялся пока там транзакция выполнялась, то монга возвращает transient transaction errors, и монгус берет и автоматом прогоняет операцию сначала. В итоге меньше ошибок отлавливать, чище код. Вобщем еще погоняем на след неделе, посмотрим насколько они хороши/плохи.

Пока нравятся.

О, ну оптимистик локинг такой себе :)

Клево. Энивей, мб я biased, ибо игрался с этим и попал на оч так себе проект в 2015 году аж.

да, эта актуальная тема. потому что я все что посмотрел в сети. выдало лишь скудные примитивы на тему RBAC.

А сравнения со 100 обращений к RBAC сервису не совсем корректно, потому что сервис может быть частью всей системы и модифицировать запросы. Достаточно элементарная штука, кстати и все запросы начинают работать ещё быстрее, т.к. там идет запрос по +1 индексу и ограничивает выборку.
Ну и есть системы. где RBAC на уровне описания данных организован и при запуске сервиса он тоже висит в памяти. Т.е. REST не ограничивается отдельным RBAC сервисом.

Однако это все про уровень безопасности сервиса. А самая проблемная часть это синхронизация знаний описания правил RBAC на сервере и согласование его с интерфейсом.
Другими словами, нужно при разработке интерфейса помнить что из запроса полей множества (A,B,C) тебе может вернуться любое подмножество. И тут начинается сильное  усложнение логики из-за этих ограничений.
А GraphQL как бы был призван упростить построение интерфейса (упростить поток данных на клиенте). Т.е. мы поулчаем что основная цель не достигается. А сервер для GraphQL серьёзно сложнее чем для REST.

Резюме, поулчаем что упростить клиентскую часть не удалось, а серверную усложнили. Вилы.
Я пока что сижу и жду, пока кто-то методологию в этом направлении разработает, но что-то мне кажется не дождусь :(

Самое неприятное, что на парах прототипа приложение на GraphQL поулчается проще чем на классическом подходе. А вот дальше оно начинает усложняться в геометрической прогрессии. Особенно с теми правилами описания доступа к данным что есть во всяких graphql-rbac* либах

ребята, а кто-нибудь делал вложенные мутации с type-graphql?

поиск по чату, уже обсуждали, и вроде к какому-то умозаключению по этому поводу пришли

в этом очень большая проблема телеги, найти в чате что-то просто невозможно

если рефните, буду благодарен

ну есть такое, не все правильно индексирует порой