search

aws / aws-appsync-community

The AWS AppSync community
https://aws.amazon.com/appsync
Apache License 2.0
506 stars 32 forks source link

Event Source Subscriptions #352

Open dyst5422 opened 6 months ago

dyst5422 commented 6 months ago

The limitation of subscriptions being tied to mutations is mind boggling to me - I would say the vast majority of meaningful applications are not simple crud behind a graphql api, and that's what AppSync's subscriptions are currently designed for.

I propose generic event sources for subscriptions instead of tying them to mutations. An EventBridge event bus is the most obvious event source as a starting place.

Have a subscription lambda resolver that is triggered with the event bridge event and the subscription arguments as inputs on every event. That resolver does whatever is necessary to return the data shape specified in the schema.

saltman424 commented 6 months ago

@dyst5422 AppSync has an established approach for your use case

Basically, create a mutation for publishing results that only the backend will invoke, use a local resolver for this mutation, and tie your subscription to this mutation

Also, you can use AWS_IAM authorization on this mutation to ensure that only your backend can invoke it

dyst5422 commented 6 months ago

I am aware of this "established approach". It pollutes the visible api and is more of a workaround than what I would consider a first class solution.

It also still does not address the constraint of the subscription response being a subset of the mutation it's associated with. If I have two clients with different needs, I have no idea what I need to resolve in this workaround mutation that satisfies all client needs.

saltman424 commented 6 months ago

I definitely see why it feels like a workaround, but I find it to be a very efficient implementation of the feature. It works well for almost any use case that one can think of, including any use case where an EventBridge-backed subscription resolver would work. And it means that the AppSync team can focus on the multitude of other features that we need. So I tend to view it as more of a creative solution than a workaround.

In terms of polluting the visible API, it depends on your use case. I like to use the GraphQL schema as a high-level map of the entire system. So on a larger project, it can be nice to see what mutations are available to trigger client subscriptions without having to dig through the code or AWS console to figure out how subscriptions are done.

As for the subset issue, I agree it would be nice to have that changed. But there are existing issues for that: https://github.com/aws/aws-appsync-community/issues/89 and https://github.com/aws/aws-appsync-community/issues/231

With that being said, I usually just try to select as much as possible from the publishing mutation so that whatever the client needs, they can get. I mean, since the backend is sending the data to the publishing mutation, it already "knows" what data the mutation should return, so it should just select as much of that data as possible.