zarusz / SlimMessageBus

Lightweight message bus interface for .NET (pub/sub and request-response) with transport plugins for popular message brokers.
Apache License 2.0
467 stars 78 forks source link

[Host] Set global default Path #290

Open W1zzardTPU opened 1 month ago

W1zzardTPU commented 1 month ago

Not sure if I missed it in the docs.

If such a feature doesn't exist, it could be modeled similar to how the settings inheritance works in the hybrid bus. i.,e. set a default, but it can be overridden when configuring individual messages

zarusz commented 1 month ago

There isn't anything like that.

Please provide an example how you'd configure it inside the AddSlimMessageBus().

It could be added, I just wonder if that's a common need across most users.

W1zzardTPU commented 1 month ago

Just something like mbb.DefaultPath("default"); and it will let us eliminate calls to .DefaultTopic (in Produce()) and .Topic (in Consume())

Right now there's a lot of repeated code when you run everything through a single path (not sure how much of an edge case that is, seems to be the norm at least for MemoryProvider I'd say)

zarusz commented 1 month ago

For memory bus, there is a nice feature to auto declare the producers/consumers and line them up in the respective topics. That prevents users from having to do declarations (including .DefaultTopic()).

Outside of the memory provider, and on the default (or inferred topic names) I was thinking about perhaps adding some interface (or lambda) that would be set centrally (or picked up from the DI) and allow the users to declare the path/topic names by convention. That would then allow us to assign topic names by message type name (or other ways). Would that be a more flexible way that would work for you?

e.g.

// called once when the .Produce() / .Consume() are configured
public interface IDefaultPathResolver 
{
    // Gets the path for a producer
    string GetPath(ProducerSettings producer);

    // Gets the path for a consumer
    string GetPath(ConsumerSettings consumer);
}

// as an option if we wanted to make these paths dynamic at the publish stage
public interface IProducerPathResolver 
{
   // Gets the path for a producer when the message is dispatched
    string GetPath(ProducerSettings producer, object message, IDictionarty<string, object> headers);
}
W1zzardTPU commented 1 month ago

Hrmm .. not sure .. maybe this mechanism could serve as a base, with a predefined Resolver that autogenerates the names, maybe with configurable prefix.