Oauth протокол авторизации

На клеймах тех же авторизацию делать можно

Я вот только не понял как graphql связан с авторизацией

тут этого никто не понял...

Ну где-то надо вешать проверку ролей

На контроллеры не повесишь, надо вешать на резолверы

Но да, связи как таковой нет

мы сделали абсолютно тупые резолверы, мидлварю, которая делала аутентификацию, и всё. а сервисы там сами разбирались кто и что. почти оаутх только проще

Не про роли, а про пермишенны речь) сейчас, бизнесдомен сильно изменен, потому может не сильно логичной задача выглядеть, в нашем домене все красиво) есть сайт со статьями, у статьи есть автор. У редактора по определенной теме и стране (скажем спорт, Россия)  есть определенные права для статьи (удалить изменить). Статьи могут видеть только фоловеры (автора или темы+страны) + рейтинг (18+,0+). Может еще несколько ролей, с такими же сложными связями, и не являющимися ролями в приложении,  но ролями по отношению к сущности "статья", и в нашем домене  чтоб высчитать некоторые пермишены нужно в некоторых случая до 5 джоинов делать. Так вот есть query в gql, Articles{items:{ID, name, permissions:{...} }} тут нет проблемы с ID и name, мы их выбираем с помощью даталодера, но в том же запросе тянуть пермишены очень тяжело по производительности, и тянуть из все в одном запросе тоже, чаще всего понадобится 2-3 из 10. Зачем вообще они нужны в gql? Изза сложных правил их расчета, лучше их один раз описать в сервисе на бэке и отдавать на фронт, чтоб при изменении ничего не ломалось, и не надо было сложных расчетов на фронте. В ресте скорее всего бы в 1-2 запроса к базе  это все делалось, изза того что не нужна эта универсальность gql.

я до сих пор не понимаю, как расчёт пермишенов отличается в ресте и gql, учитывая, что это просто протоколы запросов и ответов.

если вам надо в 2-3 из 10 случаев пермишены, и вы почему-то (непонятно только почему) не можете их загрузку описать через gql достаточно быстро, напишите метод в протокол, в класс статей. "Дай мне статьи с пермишенами, вот тебе ид"

и делайте в нём любую кастомную логику

Так не все же пермишены нужны. Мне надо для каждой страницы разный набор их, что там будет юзер делать. А описывать отдельный эндпоинт для каждой, тогда в чем вообще тут смысл и профит от gql?

ещё раз. вот сущность "статья".

как меняются пермишены на доступ к ней при переходе от реста к графкуэлю?

профит в скорости прототипирования и разработки. не надо полгода ждать, пока бэкенд команда осилит navigation properties.

есть тайный вариант 🙊

сделать самому? да ну нафиг, это ж в бекендовом коде копаться. а там дотнеты, плюс и сиквел. нет хтмл, цсс и тс.

Ну навигейшн проперти тоже делать надо в графкл и если их нет изначально тоже ждать

Говорят в телеграмме можно орфографические ошибки исправлять