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

при обрывах

но опять таки это решение может быть вредным

если много данных, можно положить клиентов и бэкенды )

надо понимать важность данных, кол-во клиентов, и еще кучу разных ньюансов

т.к. универсальных решений не существует.

=) беда в нашем случае усугубляется еще тем, что клиенту передается список ендпойнтов, по которым сдк его балансирует - в случае если один ендпойнт становится, так скажем, нездоров , он перескакивает на другой. Данные наливаются в базы с eventual consistency - то есть на одном ендпойнте А пришло быстрее Б, на другом Б пришло быстрее А. и в момент переключения подписки тоже могут искрить из за этого

Может быть мы вообще от них откажемся, даже не знаю. Пока не очень понятно как это сделать надежно

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

как-то странно вы подписки с базами связали

подписки и загрузка файлов на gql это боль.
Можно как вариант апи сделать на gql, а подписки на ws (socket.io напр. кто в курсе, как он сейчас, или есть что  посвежее?).
А чтобы была балансировка между апи (учитывая что если перед всеми бэками поставить балансировщик, который тоже может лечь) - писать к апи ещё и SDK в обязательном порядке

да, есть такое, наверное так и сделаем

по нашей блокчейновской децентрализованной архитектуре, балансировщик между ендпойнтами не поставить 🙂

ендпойнт - это такая точка децентрализации, их может быть много, подключайся хоть сразу ко всем

ну почему, отдельный докер, у которого в конфиге прописать какие эндпоинты он балансирует и всё

нет, технически понятно, но идеологически низя))

делайте единое DNS-имя для разных хостов с эндпоинтами, на него вешайте много конечных имен, пусть релозверы нагрузку ротируют)

ну докер в смысле софт, технический стек не важно

ну или пусть клиентский SDK держит у себя ридонли-реплику etcd и синхронизирует ее с остальным кластером :)

ну это да...

а вот кластер то не наш, нету кластера) есть допустим 100 ендпойнтов по всему миру, и мы по ним скачем)

и допустим 10 из них наши, а 90-чужие

данные монут храниться децентрализованно

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

Всем привет! Есть пара вопросов:
1. В JavaScript ресолвере info.fieldNodes.length может быть больше 1? Что-то у меня не получается добиться такой ситуации.
2. Есть ли какой-нибудь гайдлайн по дроблению большой схемы с перекрёстными связями на куски для удобной разработки? Натравливаю graphql-codegen (плагин typescript-resolvers) на части схемы - он падаёт с ошибкой из-за недостающих типов, натравливаю на схему целиком - он генерирует простынь с несолькими десятками типов в Resolvers, мне не нравится и хочется как-то подробить.