I believe you are referring to the OWIN pipeline. Yes, every middleware object will "get" every request, but it can simply call the next middleware in the chain immediately if it wants to. All the middleware needs to do is inspect the request any way it wants. It's as lightweight as it can possibly be.
I personally advocate API-first development. The current Web API stack does this amazingly well and is a huge improvement over the monolithic ASP.NET MVC and Web Forms stacks of yesteryear. IOW: It just works, as you state about the original ASP.NET.
I suggest looking a bit deeper into the OWIN pipeline. You'd discover just how lightweight it is compared to the old monolithic ASP.NET Web Forms stack. Additionally, Web API isn't reliant on System.Web anymore if you choose to self-host; that means the stack from http.sys to endpoint code is even lighter weight.
> Yes, every middleware object will "get" every request, but it can simply call the next middleware in the chain immediately if it wants to.
This implies that middleware should be loaded to be able to decide what do with request. All those middlewares are loaded in initialization stage. Now imagine if there is a portal with a number of areas. Surely it can reach say 100 or 200 middlewares in pipeline. All of them compiled, loaded at init stage. They may reference other types too and this implies compiling and loading them and so on and on. The website startup time may become very heavy very soon.
The current ASP.NET stack is exactly what you're describing: hundreds of modules loaded by default and it takes lots of effort (and sometimes impossible) to not load it all if you dont need it. It's still pretty fast though.
.NET Core is the other way around and you load everything you need. If that's 2 or 200 modules, that's fine. This model combined with the lightweight hosting is what allows for the million req/sec benchmarks now.
200 modules isn't much at all. Servers today are also very fast, so this is not going to be a problem. What exactly are you concerned about?
At best this is conjecture. You assume that 200 middlewares will run slowly. Too many assumptions here and throughout this thread. The benchmarks for asp.net core seem to be almost contrary to the FUD showing up around here.
> Surely it can reach say 100 or 200 middlewares in pipeline. All of them compiled, loaded at init stage.
The flexibility of the new model means that you can opt into that if you want, or not. In other words, if you can get by with 1 or 2 modules, then that's all you need to load. This is IMHO nicer then the current model.
I personally advocate API-first development. The current Web API stack does this amazingly well and is a huge improvement over the monolithic ASP.NET MVC and Web Forms stacks of yesteryear. IOW: It just works, as you state about the original ASP.NET.
I suggest looking a bit deeper into the OWIN pipeline. You'd discover just how lightweight it is compared to the old monolithic ASP.NET Web Forms stack. Additionally, Web API isn't reliant on System.Web anymore if you choose to self-host; that means the stack from http.sys to endpoint code is even lighter weight.