Mediatr: [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 [e-mail] 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 [e-mail] 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.