MinimalApi Registration for Transient Lifetime Class-based Endpoints

[nquandt]

I have been blown away by the performance and scalability of the MinimalApi implementation. Though I've found that the registration strategy gives me paralysis by indecision and also feels somewhat anti-OOP. I don't know if I want to keep my endpoints in the Program.cs file or set them up as extensions methods, but regardless the only example I've seen from the MS-Docs has been to register with a static method or Func<> delegate.

Working on many digital product driven applications I tend to want all of my functionality baked into standard DI classes. So how can I achieve this with MinimalApi?

I saw that within the code that re-swizzles delegates there is an option to pass an instance method with a delegate target. Though this instance seems to be a static object created outside of DI, and is really just for registering the method as far as I could tell.

---

What I would like is a pattern that allows we to register a Class and Method such that the class is resolved by DI and the method is ran for that instance to handle a route.

---

What I built: Femur.AspNetCore.Endpoints

I've slowly been getting my ideas down on paper and this was the first that I felt was worth sharing. This package exposes an extension method for registering a class and mapping the instance method. I do this by generating a delegate at runtime based on the options provided in the extension method. Because the standard AspNetCore implementation supports [FromServices], I take the signature of my instance method and generate a static method+delegate of the same signature PLUS adding a [FromServices] MyClass instance.

All attributes from the parameters are copied over, and all attributes on the method are copied to the new method. Meaning AspNetCore can still infer meta data and setup binding as expected. More details are in the README.md of my repo and the code is available for review.. I did publish it to Nuget incase anyone wants to use it, though I have not tested extensively, only for the cases in which I need, which are more basic "GET" this, "POST" this, with JSON. query and headers.

Usage:

// Endpoints/MyEndpoint.cs
public class MyEndpoint
{
    private readonly ILogger _logger;
    private readonly IWeatherService _weatherService;

    public MyEndpoint(ILogger<MyEndpoint> logger, IWeatherService weatherService)
    {
        _logger = logger;
        _weatherService = weatherService;
    }

    public async Task HandleAsync([FromRoute] string city, HttpContext context, CancellationToken cancellationToken)
    {
        _logger.LogInformation("Asking for temperature of {city}", city);

        var temp = await _weatherService.GetTemperatureAsync(city);

        await context.Response.WriteAsync($"The temperature is {temp}");
    }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddTransient<MyEndpoint>(); // important

var app = builder.Build();

app.MapEndpoint<MyEndpoint>("/weather/{city}", [HttpMethod.Get], i => i.HandleAsync);

app.Run();

In my repo README I also mention ways this pattern could probably be improved or applied in a more practical situation, such as putting the routepattern and methods inside the class code instead of still at the endpoint registration, though I believe that is more of a concern for the implementers of this pattern, and is much simpler to setup now that this extension method exists.

Here was the output of running FastEndpoints benchmark runner with the addition of my tool.

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
FemurEndpoint	29.98 us	0.576 us	0.511 us	0.81	0.03	2.1973	14.79 KB	0.97
FastEndpoints	36.97 us	0.729 us	1.522 us	1.00	0.06	2.4414	15.2 KB	1.00
MinimalApi	30.59 us	0.592 us	0.681 us	0.83	0.04	2.1973	14.75 KB	0.97
AspNetCoreMvc	51.60 us	0.643 us	0.570 us	1.40	0.06	3.4180	22.1 KB	1.45