Exposing MediatR RequestHandler as minimal web API using attribute routing？

[neozhu]

could you use a framework such as MediatR.WebApi which is specifically designed to integrate MediatR with web API's, it provides a simple way to expose your handlers as web api endpoints, it also allows you to specify the url and even verb(GET,POST,DELETE etc) of the request？

Another way to expose a MediatR RequestHandler as a minimal web API is by using C# Source Generators to generate the HTTP endpoints. C# Source Generators are a feature of C# 9.0 and later, which allow you to programmatically generate code at compile-time, based on the code that you've written.

[martinothamar]

This is definitely on my radar, I still have a lot of plans for the next couple of versions of Mediator but it would be cool to explore this space a bit.

I can elaborate a bit on my context here. I tend to write applications layered in onion/clean architecture style where the application layer is decoupled from the outer layer (could be ASP.NET Core, could be gRPC, whatever). I tend to have Mediator requests in the application layer and just DTOs in the outer/API layer. This means that I can execute on domain logic from HTTP API or create CLIs or batch jobs or whatever I want. In this context, it doesn't make sense to annotate the Mediator requests themselves with HTTP configuration or other infrastructure concerns.

Another option that would work in my context, was another source generator that would generate DTOs and the corresponding ASP.NET Core APIs for example based on some configuration. I would likely want to configure this in the outer layers - for example which Mediator requests to use for API endpoints and how the routing should work etc etc. This is a complex topic, and there are a lot of ways to do model binding in ASP.NET Core depending on HTTP method (thinking about FromBody, FromRoute, FromQuery and all other other options, these would have to be configurable per type).

In terms of implementation, it would definitely be a source generator here, as is the case for the Mediator implementation. The design of this feature/package would have to account for different application architectures, but I'm partial to some kind of separation between infrastructure concerns and application/service logic, which is pretty common these days.

Happy to take more input on these things