[Feature] Support header based routing

BrighterCommand / Brighter

A framework for building messaging apps with .NET and C#.

https://www.goparamore.io/

MIT License

2.04k stars 257 forks source link

[Feature] Support header based routing #376

Open iancooper opened 5 years ago

iancooper commented 5 years ago

SNS is a channel, and is a little like an exchange in RMQ, and a little like a routing key. It is possible to use a filter to send to refine the messages sent to queue subscribed to the topic using a header.

RMQ also supports a header exchange that allows headers to be used for routing.

We should support the option to route not only via the routing key, but also by a 'Brighter' header that allows you to subscribe a queue based on routing key and header.

skatersezo commented 5 years ago

I'm going to pick up this ticket and give it a try @iancooper

iancooper commented 5 years ago

@skatersezo Any joy?

skatersezo commented 5 years ago

@iancooper sorry I haven't put my hands back on this in long time.

iancooper commented 4 years ago

Put back into the backlog

honkuan86 commented 3 years ago

@iancooper , to understand you correctly, currently implementation of the AWSSQS message gateway is that the message producer will only send messages to RoutingKey, and we want to allow the gateway to recognize the topic defined in the message header as well and send the message to the topic instead. Did I understand you correctly ?

iancooper commented 3 years ago

@honkuan86 We don't support SNS filter policies when creating a subscription at the moment i.e. https://docs.aws.amazon.com/sns/latest/dg/sns-message-filtering.html.

The original idea here was instead of making this specific to one transport e.g. we would like to create a cross-transport ability to configure header-value based routing and then implement in transports that can support it. I'm less sure now that we might not just make this something that you can set on a given Subscription type

iancooper commented 9 months ago

This is back in contention for V10. There are a couple of things that we need to think about that all fall into the same space:

allowing our commandprocessor to disambiguate handlers via a "key" which could be a header key
allowing our message mappers to select the message mapper via a key, which could be a header key
subscribing to messages in a transport, based on a key, not just the raw topic name, where supported.

iancooper commented 1 week ago

Parked this one, will bring back into V11