AppSync/Graphql Multiple subscriptions or one subscriptions for multiple ids?

Question

Problem : We are trying to make a chat application using AWS product AppSync and we want to achive the best performance but we're facing problem with real time subscriptions in AppSync and Graphql where a single user will need to handle hundereds of subscription in some cases which we think is not the best solution, what do you suggest ?

Problem Example:

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

the problem with this design is that the user need to invoke this subscription and keep listening for every single conversation, which we expect to be overwheelming the client in case if the conversations quantity is huge.

Questions :

Q1 : What we are striving to achieve is one subscription for multiple (conversation_id)s, how this will be possible? These folks (https://github.com/apollographql/apollo-client/issues/2633) are talking about something similar, we tested it and it doesn't work, is it a valid solution?

Q2: Regarding Amplify; Will amplify perform well when listening for hundereds of subscription simulanuosly? does it make some sort of merging subscription and websockets or it will deal them separately?

Q3: what are your comments about these designs? where there will be a service that will braodcast(invoke mutations with clients ids) the messages for chat participants , and the client will subscribe only for a single channel . like the following: src2 : AWS AppSync for chatting application src2 : Subscribe to a List of Group / Private Chats in AWS AppSync

Answer 1

Q1/Q2

You'll have to make multiple subscriptions and the aws ios/android/amplify sdks can handle subscription handshake protocols for real-time updates to data.

Take a look here

Q3

I recommend allowing clients to subscribe to specific channels (even if that means multiple subscriptions) so that the filtering logic can be done in the service rather than client side, reducing client side code which also means you don't have to worry about maintenance or scalability.