You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same fashion that we can add DataSources like Lambda functions, EventBridge buses, and more, to AppSync GraphqlAPIs; think it would be really good if we could also attach data sources to AppSync EventAPIs.
And also attach an EventBridge bus as a publisher to a AppSync EventAPI, therefore we could send events from multiple services to clients via a bus.
Use Case
Feels like current AppSync EventAPI is missing a way to systems behind the client apps to react to subscriptions, connections and message publishes because they lack the capability to have datasources like a Lambda function or EventBridge bus.
Right now, we can:
Allow connected and subscribed clients to talk among them by publishing messages to namespaces and channels.
Fan out messages to connected and subscribed clients through EventBridge with ApiDestinations and Connections
But, it would be awesome if for example, we could add AWS Bedrock in the middle, triggering some AI work, and then spawning all subscribed clients with the result once it's ready.
Extra Request
Would be nice if incoming events apart of bringing the event detail itself, could say which connection id sent it, and to which namespace/channel. That would empower so many other use cases.
Name of the resource
AWS::AppSync::DataSource
Resource name
AWS::AppSync::Api
Description
Describe the feature
Same fashion that we can add DataSources like Lambda functions, EventBridge buses, and more, to AppSync GraphqlAPIs; think it would be really good if we could also attach data sources to AppSync EventAPIs.
And also attach an EventBridge bus as a publisher to a AppSync EventAPI, therefore we could send events from multiple services to clients via a bus.
Use Case
Feels like current AppSync EventAPI is missing a way to systems behind the client apps to react to subscriptions, connections and message publishes because they lack the capability to have datasources like a Lambda function or EventBridge bus.
Right now, we can:
But, it would be awesome if for example, we could add AWS Bedrock in the middle, triggering some AI work, and then spawning all subscribed clients with the result once it's ready.
Extra Request
Would be nice if incoming events apart of bringing the event detail itself, could say which connection id sent it, and to which namespace/channel. That would empower so many other use cases.
References
aws/aws-cdk#33458 (comment)
Thank you,
LuisK
The text was updated successfully, but these errors were encountered: