Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event Source Subscriptions #352

Open
dyst5422 opened this issue Feb 21, 2024 · 3 comments
Open

Event Source Subscriptions #352

dyst5422 opened this issue Feb 21, 2024 · 3 comments

Comments

@dyst5422
Copy link

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
Copy link

@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
Copy link
Author

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
Copy link

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: #89 and #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants