Replies: 2 comments 1 reply
-
|
Hey @gdoddsy. Best practice would be to have a queue per handler. Each handler should really only have one purpose. Brighter does support a single queue with multiple bindings to it that are handled by a single handler. However each binding has to be registered separately (one per routing key), so you're not gaining anything by not using separate queues. Also each handler can only handle one type of event. So each of your events would need to be of the same type for the handler to be registered. From what you've said this will not be the case.
This is perfectly fine, and pretty normal. We have around 300 queues across our system, each with it's own Event and Handler associated with it. |
Beta Was this translation helpful? Give feedback.
-
|
Follow up question, is it bad practice to have 1 event handler handle multiple different events? E.g. I want to do the same thing when either event a or event b happens. I was hoping to create event handler with a common base class that the 2 events would raise. The other option I see is to create the common event handler, but inherit that into 2 specific event handlers which control the subscription. I'm not sure if any of this makes sense, and if it does, I'm not sure if it's a good idea. Any thoughts, or anywhere you can point me to? |
Beta Was this translation helpful? Give feedback.
-
|
Firstly I would question why you have two events that would have the same result, if this is out of your control then fair enough. If it's within your control, consider whether these should actually be the same event? Without any knowledge of your domain or your events it's hard to say more than that. The better way to handle two events in the same way is to have two event handlers that call a common bit of code. Each handler can just new up that common class, and call a method passing in the appropriate event. No duplication of code (apart from the extra handler), each event/handler combination only has a single purpose, more clear concise code, very little extra code added. If you are absolutely dead set on having one handler for two Events, then possibly you can have both events extend a base class, and create a handler that uses that base class. I've not tested this approach, but in theory it should work. However you will still need to some sort of casting in your handler to get back to the event you wanted. I |
Beta Was this translation helpful? Give feedback.
-
Some of our business processes go through a number of events to get from start to finish. Our hope was to use a single queue that would have multiple bindings to the Exchange, and then have a single subscription for multiple commands pick things off that queue and use the routing key to execute the correct Event Handler. Is that something that Brighter can do, or do you need to have a queue per Event Handler? This answer on Stack Overflow says that we'll need 1 queue per event handler.
Is there any documentation around this, or thoughts on best practices? We're going to end up with a few hundred queues if we have to create 1 queue per event handler, and we're not sure if that's a good thing or not.
Beta Was this translation helpful? Give feedback.
All reactions