Interop with existing aspnet minimal api - request scoped classes?

[nicholas-brooks]

This is more of a "this is a bit painful, wouldn't it be nice...".

I am integrating wolverine http into an existing asp.net minimal api application. This application is multi-tenant and talks to two different database systems, one marten (postgres) and a legacy database (SAP SQL Anywhere). We use jwt tokens for auth and the jwt has an embedded tenant identifier in them which we use to determine which database to talk to (both marten and the legacy one).

The marten side uses the opts.TenantId.DetectWith<MyTenantIdDetection>() feature however the non-marten side uses a custom TenantContext request scoped object that gets populated via a aspnet middleware (app.UseMiddleware<RequestContextMiddleware>())

e.g.

internal class TenantContextHttpMiddleware(RequestDelegate next, IDiagnosticContext diagnosticContext)
{
    public async Task Invoke(HttpContext httpContext, ITenantContext tenantContext)
    {
        // we only set it if we can find it as there are some endpoints that are anonymous thus the TenantId
        // is unable to be extracted from the "User"
        if (httpContext.User.TryGetTenantId(out var tenantId))
        {
            tenantContext.SetTenant(tenantId);
        }
        
        httpContext.User.TryGetUserId(out var userId);

        diagnosticContext.Set("TenantId", tenantId);
        diagnosticContext.Set("UserId", userId);

        using (LogContext.PushProperty("TenantId", tenantId))
        using (LogContext.PushProperty("UserId", userId))
        {
            await next(httpContext);
        }
    }
}

To use the existing request scoped code we have (a lot of it references ITenantContext), we end up using a locator pattern by injecting IServiceProvider into the Wolverine Http Handler then getting the required service from that.

e.g.

public static class ExampleHandler
{
    public static async Task<Order? order> LoadAsync(Guid id, IServiceProvider serviceProvider, Request request)
    {
        var legacyDb = serviceProvider.GetRequiredService<ILegacyDb>();
        var order = legacyDb.Get<Order>(id);
        return order;
    }

    public static ProblemDetails Validate(Request request, Order? order)
    {
        if (order is null)
        {
            return new ProblemDetails {Status = 404, Detail = "No Order found with Id"};
        }

        // other validation

        return WolverineContinue.NoProblems;
    }

    [WolverinePost("/api/orders/{id:guid}/create-invoice")]
    public static (CreationResponse, IMartenOp) Post(Guid id, Request request, Order order)
    {
        // todo: 
        var invoiceId = CombGuidIdGeneration.NewGuid();
        var invoice = CreateFromOrder(invoiceId, order, request);
        return (new CreationResponse($"/api/invoices/{invoiceId}", MartenOps.Insert(invoice));
    }
}

So, the thought was, it would make life easier to be able to tell the Wolverine HTTP handlers (or the validator/loader methods) that, yes, I do wish to use these request scoped classes and I do acknowledge that performance will suffer.

e.g.

public static class ExampleHandler
{
    public static async Task<Order? order> LoadAsync(Guid id, [WolverineScoped] ILegacyDb legacyDb, Request request)
    {
        var order = legacyDb.Get<Order>(id);
        return order;
    }

    public static ProblemDetails Validate(Request request, Order? order)
    {
        if (order is null)
        {
            return new ProblemDetails {Status = 404, Detail = "No Order found with Id"};
        }

        // other validation

        return WolverineContinue.NoProblems;
    }

    [WolverinePost("/api/orders/{id:guid}/create-invoice")]
    public static (CreationResponse, IMartenOp) Post(Guid id, Request request, Order order)
    {
        // todo: 
        var invoiceId = CombGuidIdGeneration.NewGuid();
        var invoice = CreateFromOrder(invoiceId, order, request);
        return (new CreationResponse($"/api/invoices/{invoiceId}", MartenOps.Insert(invoice));
    }
}

ILegacyDb is but one example (a fake example to make the point) of the many request scoped classes we have and need to use.

Is there another way we could do this?