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