[Question] Decopuling queue receiver logic from application/domain logic

[luca-esse]

Hi, I have a worker that dequeues messages from a queue and executes some logic.

I would like to use MediatR to decopule the queue receiver logic from the application/domain logic.

Example: New message dequeued-> Execute receiver logic (eg: deadletter when invalid etc.)-> Send a MediatR request-> Handle MediatR Request-> Execute app/domain logic

Do you think that this is a valid use case for this library? Thank you

[jbogard]

Ahhhhh probably not. It's not really for durable messages. I think you might look at tools like Rebus or Mass Transit instead. There'll be a TON of missing things you'll run into.

On Mon, Mar 30, 2020 at 3:14 PM luca-esse notifications@github.com wrote:

Hi, I have a worker that dequeues messages from a queue and executes some logic.

I would like to use MediatR to decopule the queue receiver logic from the application/domain logic.

Example: New message dequeued->Deserialize the message->Send a MediatR request->Handle MediatR Request->Execute app/domain logic

Do you think that this is a valid use case for this library? Thank you

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jbogard/MediatR/issues/505, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZQMR5QCGBESHPNU6EKFTRKD4SPANCNFSM4LW4GDCA .

[luca-esse]

Hi, i'm already using MassTransit, here is proof of concept of what i want to do:

sbc.ReceiveEndpoint(host, "my_queue", endpoint =>
{
    endpoint.Handler<MyMessage>(async context =>
    {
        await mediator.Send(new MyRequest { [...] });
    });
});`

The reason is we have multiple sources for requests, eg: queue messages, gRPC API and REST API. By using MediatR we would have a nice and consistent layer of IRequestHandlers regardless of the type of application.

Do you still think that this is not a valid use case?

[jbogard]

You can try, but it might be a bit annoying to translate external messages to internal requests. I use NServiceBus a lot, and its handlers already look like MediatR ones (minus return values), and that's the biggest win. Those bus libraries have their own middleware, and I'd rather use that instead of the MediatR stuff.

On Tue, Mar 31, 2020 at 3:29 AM luca-esse notifications@github.com wrote:

Hi, i'm already using MassTransit, here is proof of concept of what i want to do:

sbc.ReceiveEndpoint(host, "my_queue", endpoint => { endpoint.Handler(async context => { await mediator.Send(new MyRequest { [...] }); }); });

There reason is we have multiple sources for requests, eg: queue messages, gRPC API and REST API. By using MediatR we would have a nice and consistent layer of IRequestHandlers regardless of the type of application.

Do you still think that this is not a valid use case?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jbogard/MediatR/issues/505#issuecomment-606467224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZQMTBECPKQKTYZSMU423RKGPXXANCNFSM4LW4GDCA .

[lilasquared]

We do this a bit today and we just serialize and deserialize the message to JSON with JsonSerializerSettings.TypeNameHandling = TypeNameHandling.Objects and it seems to work pretty well.