Unified pipeline builder and service registration

[alrz]

This is more of a rough idea rather than an API proposal so I opened up this for a discussion.

More often than not middlewares, endpoints have some services that need to be registered.

builder.Services.AddHttpLogging();
// ...
var app = builder.Build();
app.UseHttpLogging();

If you want to disable a middleware you most likely skip service registration as well. If you only add the middleware it's just an invalid usage. While the opposite is ok but you usually want these in sync.

The proposal here is to unify these two phases and allow services to be added alongside of middlewares at any point so only calling UseHttpLogging would be sufficient.

// also registers services
// optionally takes options
app.UseHttpLogging();

This way endpoints and their corresponding services can be configured in the same place to avoid misusage and providing more control to the extension on how these should match.

With this underlying API in place, it would be possible to mix service, middleware registration at any point in the pipeline but I don't see this as a downside since you would likely want to bring service registration (setup) closer to it's middleware (usage) and there would a single place to pass any options needed.

[davidfowl]

Did you figure out how this would actually work? The difficulty is that the middleware order is important but often service registration order is not (if you're not adding multiple implementations). On top of that, the DI container can't be mutated after its created (that's by design). This leads to this 2-phase model that has been with ASP.NET Core for the last 10 years.

[alrz]

The difficulty is that the middleware order is important but often service registration order is not

That would be still true, this is only to make both available off of the same builder. I would imagine an analogy would be UseEndpoints which is not necessary if you're using minimal APIs - you could use Map* directly. I am not sure if these two use the same underlying machinery, but on the surface it looks like endpoint APIs are merged into the parent builder.

On top of that, the DI container can't be mutated after its created

So is the pipeline - as far as I know you can't inject middlewares post-build (I may have missed your point here) but merely building the pipeline itself doesn't need DI. The builder is only responsible for the setup phase, anything else will happen when the builder is sealed i.e. after calling Run (a la deferred execution or lazy evaluation in linq).

I guess my question is what functionality could be really missing if the two phases are merged. I'm thinking all the essential services could be made available off the same builder the same way Configuration and Environment are (these used to get injected into the Startup constructor or Configure method).