ASP.NET Core | Request pipeline or middleware pipeline

A request pipeline or middleware pipeline consists of a sequence of request delegates which are called one after another to perform operations before and after the next delegate. For more about request processing pipeline for ASP.NET MVC visit Request Processing Pipeline.

The ASP.NET Core request pipeline consists of a sequence of request delegates, called one after the other. The following diagram demonstrates the concept. The thread of execution follows the black arrows.

Request processing pattern showing a request arriving, processing through three middlewares, and the response leaving the app. Each middleware runs its logic and hands off the request to the next middleware at the next() statement. After the third middleware processes the request, the request passes back through the prior two middlewares in reverse order for additional processing after their next() statements before leaving the app as a response to the client.

Each delegate can perform operations before and after the next delegate. Exception-handling delegates should be called early in the pipeline, so they can catch exceptions that occur in later stages of the pipeline.

The simplest possible ASP.NET Core app sets up a single request delegate that handles all requests. This case doesn't include an actual request pipeline. Instead, a single anonymous function is called in response to every HTTP request.

C#
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run();

Chain multiple request delegates together with Use. The next parameter represents the next delegate in the pipeline. You can short-circuit the pipeline by not calling the next parameter. You can typically perform actions both before and after the next delegate, as the following example demonstrates:

C#
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    // Do work that can write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

app.Run();

Comments

Post a Comment

Popular posts from this blog

ASP.NET Core | Change Token

A  change token  in ASP.NET Core is a general-purpose, low-level building block used to track state changes. Let me break it down for you: IChangeToken Interface : The  IChangeToken  interface propagates notifications that a change has occurred. It resides in the  Microsoft.Extensions.Primitives  namespace and is implicitly provided to ASP.NET Core apps via the  Microsoft.Extensions.Primitives  NuGet package. Key properties: ActiveChangeCallbacks : Indicates whether the token proactively raises callbacks. If set to  false , a callback is never called, and the app must poll  HasChanged  for changes. HasChanged : Receives a value that indicates if a change has occurred. Additionally, it includes the  RegisterChangeCallback(Action<Object>, Object)  method, which registers a callback invoked when the token changes 1 . ChangeToken Class : The  ChangeToken  class is static and used to propagate notifications that...
Read more

ASP.NET Core | Open Web Interface for .NET (OWIN)

Image
ASP.NET Core supports the Open Web Interface for .NET (OWIN). OWIN allows web apps to be decoupled from web servers. It defines a standard way for middleware to be used in a pipeline to handle requests and associated responses. ASP.NET Core applications and middleware can interoperate with OWIN-based applications, servers, and middleware. Running OWIN middleware in the ASP.NET pipeline ASP.NET Core’s OWIN support is deployed as part of the  Microsoft.AspNetCore.Owin  package. You can import OWIN support into your project by adding this package as a dependency in your  project.json  file: "dependencies" : { "Microsoft.AspNetCore.Server.IISIntegration" : "1.0.0" , "Microsoft.AspNetCore.Server.Kestrel" : "1.0.0" , "Microsoft.AspNetCore.Owin" : "1.0.0" }, OWIN middleware conforms to the  OWIN specification , which requires a  Func<IDictionary<string,   object>,   Task>  interface, and...
Read more

How will you improve performance of ASP.NET Core Application?

Cache aggressively Caching is discussed in several parts of this article. For more information, see  Overview of caching in ASP.NET Core . Understand hot code paths In this article, a  hot code path  is defined as a code path that is frequently called and where much of the execution time occurs. Hot code paths typically limit app scale-out and performance and are discussed in several parts of this article. Avoid blocking calls ASP.NET Core apps should be designed to process many requests simultaneously. Asynchronous APIs allow a small pool of threads to handle thousands of concurrent requests by not waiting on blocking calls. Rather than waiting on a long-running synchronous task to complete, the thread can work on another request. A common performance problem in ASP.NET Core apps is blocking calls that could be asynchronous. Many synchronous blocking calls lead to  Thread Pool starvation  and degraded response times. Do not  block asynchronous execution by...
Read more