Implement an Auto Responder?

Let me start by saying that I love the Auto Subscriber.

From what I can see in the wiki, the “respond” side of the request/response pattern appears very similar to the “subscribe” side of the publish/subscribe pattern (albeit, a little different; for example, there’s no subscription ID).

publish/subscribe

bus.Subscribe<MyMessage>("my_subscription_id", msg => Console.WriteLine(msg.Text));

request/response

bus.Respond<MyRequest, MyResponse>(request => new MyResponse { Text = “Responding to “ + request.Text});

That said, I still don’t want to manually manage and wire up all of the “respond” handlers in my application. I figure we could provide an AutoResponder just like the AutoSubscriber.

Allow me to make some initial suggestions as to what’s required. I’m only just brushing up on the async and signature changes in the 4.0 release, so I’ll spec only the async methods, but I might get them a bit wrong as I browse the latest changes!

AutoRespond.cs

namespace EasyNetQ.AutoRespond
{
    public class AutoResponder
    {
        protected readonly IBus bus;

        public AutoResponder(IBus bus);

        public IAutoResponderMessageDispatcher AutoResponderMessageDispatcher { get; set; }

        public virtual async Task<IDisposable> RespondAsync(Type[] responderTypes, CancellationToken cancellationToken = default)
    }
}

IAutoResponderMessageDispatcher.cs

namespace EasyNetQ.AutoRespond
{
    public interface IAutoResponderMessageDispatcher
    {
        TResponse Dispatch<TRequest, TResponse, TResponder>(TRequest request, CancellationToken cancellationToken = default)
            where TRequest : class
            where TResponse : class
            where TResponder : class, IRespond<TRequest, TResponse>;

        Task<TResponse> DispatchAsync<TRequest, TResponse, TResponder>(TRequest request, CancellationToken cancellationToken = default)
            where TRequest : class
            where TResponse : class
            where TResponder : class, IRespondAsync<TRequest, TResponse>;
    }
}

IRespond.cs

namespace EasyNetQ.AutoRespond
{
    public interface IRespond<TRequest, TResponse>
        where TRequest : class
        where TResponse : class
    {
        TResponse Respond(TRequest request, CancellationToken cancellationToken = default);
    }
}

IRespondAsync.cs

namespace EasyNetQ.AutoRespond
{
    public interface IRespondAsync<TRequest, TResponse>
        where TRequest : class
        where TResponse : class
    {
        Task<TResponse> RespondAsync(TRequest request, CancellationToken cancellationToken = default);
    }
}

[AnthonyMastrean]

Obviously, let me know if this is something you even want. I can’t think of why you wouldn’t but, hey, it’s not my project 🤗

I’m getting the same feelings working through the send/receive pattern…

bus.Receive<MyMessage>("my.queue", message => Console.WriteLine("MyMessage: {0}", message.Text));

https://github.com/EasyNetQ/EasyNetQ/wiki/Send-Receive

I’m actually implementing the “auto” classes now in a private project. If they work out and you’re interested, after all, I’ll send up a PR. To go a step further, if you want auto subscribe, respond, and receive and the impl. ends up looking good… would you consider an even more generic “auto wire all”?

[AnthonyMastrean]

OK! I’m willing to tackle this… I can start something under my own account, link it here, and see how it turns out? What do you think about the term “AutoRegistration” as an umbrella to cover all of the relevant messaging patterns?