AppSync / Graphql Несколько подписок или одна подписка на несколько идентификаторов? - PullRequest
1 голос
/ 18 марта 2019

Проблема: Мы пытаемся создать приложение для чата с использованием продукта AWS AppSync, и мы хотим добиться максимальной производительности, но мы сталкиваемся с проблемой подписок в реальном времени в AppSync и Graphql, когда одному пользователю в некоторых случаях придется обрабатывать множество подписок, которые мы думаю, не лучшее решение, что вы предлагаете?

Пример задачи:

Mutation{
    addMessage(conversation_id=Int!, content:String!) : Message
}
Subscription{
   subscribeForNewMessages(convesration_id: Int!):Message
        @aws_subscribe(mutations: ["addMessage"])
}

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

Вопросы:

Q1: Чего мы стремимся достичь, так это одной подписки на несколько (dialog_id), как это будет возможно? Эти люди (https://github.com/apollographql/apollo-client/issues/2633) говорят о чем-то похожем, мы проверили это, и оно не работает, это правильное решение?

Q2: Относительно Amplify; Будет ли усиление выступать хорошо при одновременном прослушивании сотен подписчиков? это делает какое-то слияние подписки и веб-сокетов или будет раздавать их отдельно?

3: каковы ваши комментарии по поводу этих конструкций? где будет служба, которая будет транслировать (вызывать мутации с идентификаторами клиентов) сообщения для участников чата, а клиент будет подписываться только на один канал. как следующее: src2: AWS AppSync для приложения чата src2: Подписаться на список групповых / приватных чатов в AWS AppSync

1 Ответ

0 голосов
/ 19 марта 2019

Q1 / Q2

Вам нужно будет сделать несколько подписок, и SDK aws ios / android / ampify может обрабатывать протоколы рукопожатия подписки для обновления данных в реальном времени.

посмотрите здесь

Q3

Я рекомендую разрешить клиентам подписываться на определенные каналы (даже если это означает несколько подписок), чтобы логика фильтрации могла быть выполнена в сервисе достаточночем на стороне клиента, сокращая код на стороне клиента, что также означает, что вам не нужно беспокоиться об обслуживании или масштабируемости.

...