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
Today, the @klotho::pubsub annotation only supports events that are processed by emitter.on in a Klotho-enabled exec unit. In other words, Klotho really wants to handle both sides of the event: emitting and processing. It would be nice if we could provide a way for people to listen to events from non-Klotho hardware.
Since the processing code isn't under Klotho, there's no place that would make sense to put a Klotho annotation for this. Instead, we should put it as a configuration option, in some way.
I could see this happening in a couple different ways:
we could require that customers create the SQS queue themselves, and then just provide the ARN in the Klotho config for the pubsub
we could have customers declare the SQS parameters they want, and then we'd generate the IaC to create the queue and provide its ARN as a stack output
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Today, the
@klotho::pubsub
annotation only supports events that are processed byemitter.on
in a Klotho-enabled exec unit. In other words, Klotho really wants to handle both sides of the event: emitting and processing. It would be nice if we could provide a way for people to listen to events from non-Klotho hardware.Since the processing code isn't under Klotho, there's no place that would make sense to put a Klotho annotation for this. Instead, we should put it as a configuration option, in some way.
I could see this happening in a couple different ways:
Beta Was this translation helpful? Give feedback.
All reactions