Brighter
Brighter copied to clipboard
BrighterCommand
[Feature] ASB - Add an option to use ServiceBus Queues
Discussed in https://github.com/BrighterCommand/Brighter/discussions/2243
I would like to able to use Brighter for service bus queues in case of commands. There's an option of using a topic with one subscription for a command but this does not help if you already have multiple services with multiple queues setup.
As part of the subscriptions you can choose whether you want to use a Topic or a Queue. In case of the publisher the only thing that needs to change is the validation incase of a queue we need to trigger queue validation and not a topic validation.
@ransht where you asking about this as well. @preardon we should chat about the ability to target a queue directly (ASB, SQS)
@iancooper Happy to chat about this, the only benefit I really see is that Topics aren't available on the lowest tier, but should, in theory be a small change
Let's pick up. It may make sense as we tend to argue for using streams and queues appropriately
ok, I'll see if I can take some time in the next week or 2 to take a run at it now that I'm back from holidays, I suppose my only questions is do we want to specify the ability to have all comamnds go to Queues and all Events go to Topics?
@iancooper
The PR for this is in ( #3144 ) The questions is do we want to have this on a topic Channel by Channel basis or do we want a more specific All Commands go to Queues?
The Benefit of this approach is that you can have a shift of both, although it might be annoying for people who want to run their entire Command estate off of queues as this will require configuration on each Publication and Subscription?
Let me know your thoughts?
The PR for this is in ( #3144 ) The questions is do we want to have this on a topic Channel by Channel basis or do we want a more specific All Commands go to Queues?
Thinking about this from the point of view of SNS/SQS where we have a similar dichotomy on AWS, the answer would be that you could configure a given producer/publication as being to a queue or a topic (you always consume via a queue in AWS which may be different in Azure). Normally a queue would be a point-to-point/one-to-one, allowing you to leave SNS for one-to-many. The API exposed by the provider would tell you whether you needed a queue, I expose an operation that you call, as opposed to you listen to my notifications.
As a channel is a "named virtual pipe" it can represent either a topic or a queue. So it just the "name" that changes, from the point of view of Brighter, you don't want to leak implementation to the client beyond configuration I think.