AppSync/Graphql 多个订阅还是一个订阅多个 id？答案

【问题标题】：AppSync/Graphql Multiple subscriptions or one subscriptions for multiple ids?AppSync/Graphql 多个订阅还是一个订阅多个 id？
【发布时间】：2019-08-09 01:13:39
【问题描述】：

问题：我们正在尝试使用 AWS 产品 AppSync 制作聊天应用程序，我们希望获得最佳性能，但我们在 AppSync 和 Graphql 中面临实时订阅问题，在某些情况下，单个用户需要处理数百个订阅，我们认为不是最好的解决方案，您有什么建议？

问题示例：

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

这种设计的问题是用户需要调用这个订阅并继续监听每一个对话，如果对话数量很大，我们预计这会让客户端不堪重负。

问题：

第一季度：我们正在努力实现的是一个订阅多个（conversation_id），这怎么可能？这些人 (https://github.com/apollographql/apollo-client/issues/2633) 正在谈论类似的事情，我们对其进行了测试，但它不起作用，这是一个有效的解决方案吗？

第二季度：关于放大；在同时收听数百个订阅时，amplify 会表现良好吗？它会进行某种合并订阅和 websockets 还是会单独处理它们？

第三季度：您对这些设计有何看法？将有一项服务将广播（使用客户端 ID 调用突变）聊天参与者的消息，并且客户端将仅订阅单个频道。如下所示： src2：AWS AppSync for chatting application src2 : Subscribe to a List of Group / Private Chats in AWS AppSync

【问题讨论】：

标签： facebook graphql chat aws-appsync real-time-data

【解决方案1】：

第一季度/第二季度

您必须进行多个订阅，并且 aws ios/android/amplify sdks 可以处理订阅握手协议以实时更新数据。

看看here

第三季度

我建议允许客户端订阅特定频道（即使这意味着多个订阅），以便过滤逻辑可以在服务而不是客户端完成，减少客户端代码，这也意味着您不必担心关于维护或可扩展性。

【讨论】：