Ilya я уже про это написал. Мы говорим о данных с сервера. Аполло только для UI это overkill :)

Потому что есть state и есть context api. Redux тоже не нужен

Как? Возможно есть что то о чем я не знаю

Всем привет.
Насчет авторизации в graphql: мне не нравится идея определения прав в резолверах, как и не нравится использование для этого директив.
Не нравится мне это из-за того, что у меня в проекте уже сейчас 4 роли пользователей, а планируется еще больше. Я не хочу , чтобы незарегистрированный пользователь  даже видел в своей схеме запросы/мутации для администратора.
Это усложняет использование песочницы, это приводит к дополнительным затратам при разработке в dev-режиме (схема пользователя весит много, а он public), да и дает внешним силам видеть мою схему.

Моя идея такая - поднимать один сервер для всех, но внутри node.js приложения поднимать несколько apollo-server'ов на закрытых портах.
Каждый apollo-server нужен для определенного типа пользователя, имеет собственную схему.
Public сервер выполняет роль определения типа пользователя и проксирования запроса на нужный apollo-сервер.

Только вот у меня не хватает знаний оценить такое решение с точки зрения используемых ресурсов. Может кто поможет?

Нормальное решение. Ну будет у тебя в памяти в 4 раза больше типов и функций. И ничего страшного. Нода такую ерунду переварит. Вот если будет 40-100 ролей, тогда уже надо будет считать.

Если извернуться, то вообще можно один ендпоинт на одном порту оставить. И считывая из заголовков/кук передавать в graphql нужную схему.

Глянь мое выступление на holyjs от ноября 2018. Я там рассказываю как это работает.

В том плане, что в компании уже сформировалась политика написания документации в swagger. Помимо этого довольно скептически отношусь к GraphiQL в виде документации на проде. Ведь небезопасно хранить всю информацию о схемах в таком формате

Возможно, я не до конца понимаю workflow работы с GraphQL API. Раньше писал только REST API, документировал все в Swagger.