Amplify-cli: Support for dynamic groups subscriptions with @auth 2.0

[rawadrifai]

Is your feature request related to a problem? Please describe.
This related to https://github.com/aws-amplify/amplify-cli/issues/1043
Subscriptions auth is not sophisticated enough to support a generic use case, a messenger like Slack. The reason is lack of support for Dynamic groups in the 2.0 update for the cli.

Take a very simple use case. A user inserts a message record in the messages table. The message is directed at a channel. The members of the channel are dynamic and may change anytime. Subscriptions should be aware of who belongs in the channel.

Static groups cannot possibly support a use case like this. Every message comes with different permissions, depending whether it's a channel message, a conversation, a group conversation, etc. I tried to design it with static groups, it's just impossible.

Describe the solution you'd like
Subscriptions should support dynamic groups.
For the developer it should be as simple as:

onCreateMessage.subscribe($filter)

If there is no filter, it sends events for all messages that the user subscribing is authorized to see. Mimic what is done for queries. Same behavior. * If I can read it, I should get an event. *

If a filter is provided, it applies additional filtering on an attribute provided in the filter.

Describe alternatives you've considered
I am considering using the owner field instead with an array of strings. So every message would contain all of the users that are authorized to see it. That is of course very inefficient but it's the only thing possible today.

Additional context
I think Amplify will render itself unusable if dynamic groups are not support by subscriptions auth. We are trying to push for the best for the framework. We are too deep in it now to change frameworks, so we hope you would support this as soon as possible.

[rawadrifai]

@undefobj There you go, separate issue.

[rawadrifai]

@yuth thanks for taking a look at this. Mind keeping us in the loop as you discuss this with the team? Happens to be a sensitive time for us with this being a critical requirement. Thank you!

[AntonioAngelino]

@undefobj any update on this issue?

We are evaluating AWS Amplify + AppSync, but having subscriptions w/o dynamic group filtering is a no go for us 😞

[mlecoq]

Same for us, I was very interested in Datastore + Appsync to migrate our app, is there any chance that it will be supported before the end of the year ?

[ricsirigu]

I'm experiencing the same issue. Without dynamic groups subscriptions, It's useless for our use case

[sambwest]

Same here

[mikedizon]

Same

[mdoesburg]

Same

[avlonder]

Same

[pmclachlan]

From my experimentation, it seems that if you need to use dynamic group @auth, you can't use DataStore at all, right? Because DataStore simply fails to initialize if it doesn't have permission to all the subscriptions. Makes all this a tough sell. :(

[sacrampton]

@pmclachlan - this is a huge thing to get confirmed. I'm finding with DataStore its 1 step forward then 2 steps back as you try to get it working. Couldn't support types without @model - couldn't co-exist with ElasticSearch (@searchable) to name but two. Those have now been addressed, but still not sure its all there yet. Thanks for posting this warning. DataStore really does need to work as we need offline search - but if dynamic group @auth is not there I agree with you that it would kill it.

[lucido-apps]

I was asking about this issue on Amplify's chat and @undef_obj wrote the following there:

Dynamic Groups isn't unsupported in DataStore. The limitation you're referring to is Dynamic Groups with GraphQL subscriptions in general. AuthZ happens at connection time which is why dynamic groups function for queries and mutations since they are request/response based. Subscriptions are websockets so after AuthZ happens there's nothing at runtime to perform validation against, therefore you cannot do this dynamic check against a data source.
We're working through possibilities of doing runtime filtering with the AppSync team on their roadmap which would open up this capability. That being said almost all systems do runtime filtering at clients and AuthZ happens on connections just like this since it's the most scalable solution.

Link to chat message: https://discord.com/channels/705853757799399426/707328986077855836/717886780535472188

[sacrampton]

Hi @lucido-apps - thanks for posting this. Given all the grief that Dynamic Groups causes Subscriptions & Data Store sounds like need to look at another approach. Hope this doesn't sound like too much of a dumb question, but is anyone able to provide any more input/references on this last line in the statement? Would seem like the @auth is of extremely limited use and everything should happen on the client. Is that a fair statement?

"_That being said almost all systems do runtime filtering at clients and AuthZ happens on connections just like this since it's the most scalable solution._"

[lucido-apps]

Here's an example app demonstrating this issue (uses only AppSync, not DataStore): https://github.com/lucido-apps/appsync-dynamic-groups-subscribe

And a video: https://youtu.be/O7rofaqRdaU

Hopefully this is useful for troubleshooting!

[lucido-apps]

@rawadrifai How could the alternative (workaround) you mentioned above be implemented? Do you have an example of this by any chance?

I am considering using the owner field instead with an array of strings. So every message would contain all of the users that are authorized to see it. That is of course very inefficient but it's the only thing possible today.

Changing owner field to an array doesn't make subscriptions work for me for tasks shared by multiple users. Moreover, even same-owner subscriptions stop working when I set the owner field to an array...