я знаю) мы делали raw subscriptions голыми руками)

в стандарте - делаешь подписку и в ответ должен прилететь ответ на этот запрос (тавталогия негодуэ)

ну так gql работает

просто этот ответ, в полном его виде может ещё и обновляться

обновление - это всего лишь оповещение, что по какому-то пути новые данные

например по user.friends в пуле этих данных (т.е. новый список друзей)

а дальше отдаётся то, что и так есть внутри пула (включая новые данные)

я доступно объяснил?)

Но опять же "почти" - означает, что надо сделать вид, что обновление этого списка "friends" пришло из резолвера, а не из пула данных. Т.к. резолвер ещё и сериализует, и валидирует и прочее, а мне этого пока не удалось добаиться.

Ну вот тут два подхода:
— либо ты отсылаешь ивент с __typename + id того что изменилось, а в резолвере делаешь запрос в БД:
в таком случае в БД на один ивент обновления чего-то может отослаться 10000 запросов, если будет 10000 подписок.
В твоем случае из всех резолверов придет 10000 запросов в пул (redis или что у тебя там)
— либо во время ивента вычислять и отправлять полный набор необходимых данных для всех резолверов (тупо ссумируешь все поля и данные, в которых нуждаются ВСЕ подписчики) и уже в резолверах graphql отфильтрует то что нужно отправить

во втором случае непонятно как будут работать запросы с сортировкой, например

если разные клиенты хотят данные с разной сортировкой

в общем все это очень сложно)

было бы круто подписки с одинаковым контекстом (аргументы, права пользователя) стакать в один резолвер

чтобы 1000 юзеров, которые подписались на одни и те же данные с одними и теми же аргументами породили только один запрос в пул

graphql под ноду из коробки это не позволяет делать

может я что-то упускаю

Да не надо ничего отсылать, т.к. эти данные и так есть внутри пула

и запросы никакие делать не надо

а еще по хорошему знать к какому из 300 инстансов подключен твой клиент и только на этот инстанс отправлять обновление, а не на все инстансы