если чуть подробнее напишете, буду благодарен)
Прочитал документацию по вебсокетам, но там об этом ничего нет

вы про подписки или вебсокеты?

про подписки

Я увы не знаю как вы вообще проверяете куки)
На вскидку три метода:
- Директивы (мидлвара по сути, только с контекстом gql)
- Обычная мидлвара на http или любой другой сервер.
- Внутри резолверов

Apollo grapqhl описывает пользование Upload скалярами, причем они вшиты в apollo server, хоть это и не парадигма gql, но есть такой вот best practice, а playground очень удобен в разработке, когда есть все под рукой

Альтаир ну вот ничем не отличается, серьезно, ладно бы там чего то не хватало.

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

Там мало вариантов. Нет стандартного способа как у http
я делаю подписки с аргументом токен
sendMessage(token: String!)

В вашем случае можно сделать мутацию
genSubscribeUrl: String!

Которая вернет ссылку вида
/ws?token=mytoken

и при подписке сможете увидеть токен. Хотя проще мутацию, которая вернут по запросу токен без механизма кук

Он немного на другом уровне просто

перед connection.context нужно его туда как то засунуть и я говорю, что нет стандартных способов

В директивах он есть

Понял. Спасибо

у websocket нет стандартного способа авторизации. Это не касается graphql. О чем вы говорите? Есть какие-то костыли, но это не стандарт

а знаете почему телеграм ссылку показывает как фото?
потому что скриншоты по ссылке неудобны нихрена, телеграм предусмотрительно придумал CTRL+V для картинок...

То есть работа с схемой через директивы не стандарт, окей)
Контекст доступен - доступен. Костылем выглядит решение отдельного запроса на токен

Хотя если у вас не http only куки, тогда понятно отчего проблемы :)

у меня react native один из клиентов, который не поддерживает cookie based авторизацию и доп параметры в handshake. На ios/android тоже не все гладко. По итогу токен в аргументы для подписок - самый простой/универсальный путь.

всем привет! есть объект, который может быть в состоянии "черновик" и "новый". сделал схему, в которой на этот объект в состоянии "новый" наложил ограничения required (!) и т.п. теперь, для состояния "черновик" нужно некоторые ограничения отключить. пока кроме как создавать две модели объекта в схеме которые будут отличаться наличием "!" в спецификации поля других вариантов не вижу. есть ли другие варианты, в которых не надо будет дублировать описание объектов? объектов таких много и количество полей в них тоже, будет большая вероятность при новых изменениях где то что то забыть подправить)

недавно graphql с typescript смотрел и пришел к выводу, что в этой связке они избыточны. В схеме на бэке ты задаешь типы, на фронте тоже задавать приходится. Поэтому пришел к выводу, что с graphql лучше использовать js.