How to create and use middleware in asp.net core

Middleware is piece of code that's assembled into an app pipeline to handle requests and responses. 

• Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline or short-circuiting the pipeline. 
• each component can perform work before and after the next component in the pipeline.

Request delegates are used to build the request pipeline.

Request delegates are configured using Run, Map, and Use extension methods. 

UseWhen also branches the request pipeline based on the result of the given predicate. Unlike with MapWhen, this (UseWhen) branch is rejoined to the main pipeline if it doesn't short-circuit or contain a terminal middleware.

app.UseWhen(context => context.Request.Query.ContainsKey("branch"),appBuilder => HandleBranchAndRejoin(appBuilder));

Custom Middleware: We can create custom middleware either by convention or impelementing IMiddle<T> interface.

Convention (Class) based Middleware: Following point need to remember while creating conventional middleware:

• A public constructor with a parameter of type RequestDelegate.
• A public method named Invoke or InvokeAsync. This method must return a Task and accept a first parameter of type HttpContext.
• Additional parameters for the constructor and Invoke/InvokeAsync are populated by dependency injection (DI).

To use this middleware, we need to call USEMIDDLEWARE<CLSNAME>() extension method.

Note: Class based (Conventional) middleware has a singleton scope (application lifetime).

Per-request middleware dependencies

Middleware is constructed at app startup and therefore has application lifetime. Scoped lifetime services used by middleware constructors aren't shared with other dependency-injected types during each request. To share a scoped service between middleware and other types, add these services to the InvokeAsync method's signature. The InvokeAsync method can accept additional parameters that are populated by DI.

Factorybased Middleware

UseMiddleware extension methods check if a middleware's registered type implements IMiddleware. If it does, the IMiddlewareFactory instance registered in the container is used to resolve the IMiddleware implementation instead of using the convention-based middleware activation logic. The middleware is registered as a scoped or transient service in the app's service container.

IMiddleware is activated per client request (connection), so scoped services can be injected into the middleware's constructor.

IMiddleware defines middleware for the app's request pipeline. The InvokeAsync(HttpContext, RequestDelegate) method handles requests and returns a Task that represents the execution of the middleware.

USE: builder.Services.AddTransient<FactoryActivatedMiddleware>(); 

FactoryActivatedMiddleware is the name of class implements IMiddleware.

Docker commands

 Below are the some basic docker commands:

FROM: The FROM instruction specifies the base image that the container will be built on top of. This instruction is typically the first one in a Dockerfile and is used to set the base image for the container. The format of the instruction is:

FROM <image>

For example:

FROM node:14-alpine3.16

This instruction tells Docker to use the node:14-alpine3.16 image as the base image for the container. To use a specific version or tag of an image you can use:<version> or:<tag> syntax.

WORKDIR : In a Dockerfile, the WORKDIR instruction sets the working directory for any command that follows it in the Dockerfile. This means that any commands that are run in the container will be executed relative to the specified directory.

WORKDIR <directory>

For example:  WORKDIR /app

This instruction tells Docker to set the working directory of the container to /app . Any subsequent commands in the Dockerfile, such as COPY, RUN, or CMD, will be executed in this directory.

It’s important to note that the WORKDIR instruction creates the directory if it does not already exist. And the subsequent COPY and ADD commands will be executed relative to the WORKDIR specified.

COPY: Use the COPY instruction to copy local files from the host machine to the current working directory. For example, to copy a file named package.json from the host machine’s current directory to the image’s /app directory, you would use the following command:

COPY package.json /app/

If you want to copy all the files from the host’s current directory to the container’s current directory, you can use the below command:

COPY . .

It is used to copy all files and directories from the current directory on the host machine (indicated by “.”) to the current directory within the container. The first “.” refers to the source directory on the host machine, and the second “.” refers to the destination directory within the container.

RUN: Use the “RUN” instruction to execute commands that will run during the image build process. The format of instruction is :

RUN <command_name>

For example, to update the package manager and install a specific package, you would use the following command:

RUN npm install

CMD: In a Dockerfile, the CMD instruction sets the command that will be executed when a container is run from the image. The format of the instruction is:

CMD ["executable","param1","param2",...]

For example:

CMD ["npm", "start"]

This instruction tells Docker to run the command npm start when a container is created from the image. This command will start the Node.js application that was installed in the container using the npm install command.

ENV: Use the ENV instruction to set environment variables inside the image which will be available during build time as well as in a running container. For example, to set the NODE_ENV environment variable to production, you would use the following command:

ENV NODE_ENV production

EXPOSE: Use the EXPOSE command to tell Docker which ports the container will listen on at runtime. For example, if your application listens on port 9000, you will use the following command:

EXPOSE 9000

Notes : filters in asp.net core

======================Middleware vs filters========

The main difference between them is their scope. Filters are a part of MVC, so they are scoped entirely to the MVC middleware. Middleware only has access to the HttpContext and anything added by preceding middleware. In contrast, filters have access to the wider MVC context, so can access routing data and model binding information 

for example.

Generally speaking, if you have a cross-cutting concern that is independent of MVC then using middleware makes sense, if your cross-cutting concern relies on MVC concepts, or must run midway through the MVC pipeline, then filters make sense.

==============================

ConsumesAttribute—Can be used to restrict the allowed formats an action method can accept. If your action is decorated with [Consumes("application/json")] but the client sends the request as XML, then the resource filter will short-circuit the pipeline and return a 415 Unsupported Media Type response.

==============================

 Exception filters can catch exceptions from more than your action methods.

They’ll run if an exception occurs in MvcMiddleware

 During model binding or validation

 When the action method is executing

 When an action filter is executing

You should note that exception filters won’t catch exceptions thrown in any filters

other than action filters, so it’s important your resource and result filters don’t throw

exceptions. Similarly, they won’t catch exceptions thrown when executing IActionResult itself. 

================================

ProducesAttribute—This forces the Web API result to be serialized to a specific output format. For example, decorating your action method with [Produces("application/xml")] forces the formatters to try to format the response as XML, even if the client doesn’t list XML in its Accept header.

FormatFilterAttribute—Decorating an action method with this filter tells the formatter to look for a route value or query string parameter called format, and to use that to determine the output format. For example, you could call /api/recipe/11?format=json and FormatFilter will format the response as JSON, or call api/recipe/11?format=xml and get the response as XML.

======================================

As with resource and action filters, result filters can implement a method that runs after the result has been executed, OnResultExecuted. You can use this method, for example, to inspect exceptions that happened during the execution of IActionResult.

========================================

Generally, you can’t modify the response in the OnResultExecuted method, as MvcMiddleware may have already started streaming the response to the client.

========================================

The most interesting point here is that short-circuiting an action filter doesn’t shortcircuit much of the pipeline at all. In fact, it only bypasses later action filters and the action method execution itself. By primarily building action filters, you can ensure that other filters, such as result filters that define the output format, run as usual, even when your action filters short-circuit. 

=======================================

The previous version of ASP.NET used filters, but they suffered from one problem in particular: it was hard to use services from them. This was a fundamental issue with implementing them as attributes that you decorate your actions with. C# attributes don’t let you pass dependencies into their constructors (other than constant values), and they’re created as singletons, so there’s only a single instance for the lifetime of your app.

========================================

the key is to split the filter into two. Instead of creating a class that’s both an attribute and a filter, create a filter class that contains the functionality and an attribute that tells MvcMiddleware when and where to use the filter.

a class implements IACtionFiler and Anoter class derived from TypeFilerAttribute, in this class we will pass type of IActionFiler implementing class so this will work as attribute.

===================================

Summary

 The filter pipeline executes as part of MvcMiddleware after routing has selected an action method.

 The filter pipeline consists of authorization filters, resource filters, action filters, exception filters, and Result filters. Each filter type is grouped into a stage.

 Resource, action, and result filters run twice in the pipeline: an *Executing method on the way in and an *Executed method on the way out.

 Authorization and exception filters only run once as part of the pipeline; they don’t run after a response has been generated.

 Each type of filter has both a sync and an async version. For example, resource filters can implement either the IResourceFilter interface or the IAsyncResourceFilter interface. You should use the synchronous interface unless your filter needs to use asynchronous method calls.

 You can add filters globally, at the controller level, or at the action level. This is called the scope of the filter. Within a given stage, global-scoped filters run first, then controller-scoped, and finally, action-scoped.

 You can override the default order by implementing the IOrderedFilter interface. Filters will run from lowest to highest Order and use scope to break ties.

 Authorization filters run first in the pipeline and control access to APIs. ASP.NET Core includes an [Authorization] attribute that you can apply to action methods so that only logged-in users can execute the action.

 Resource filters run after authorization filters, and again after a result has been executed. They can be used to short-circuit the pipeline, so that an action

method is never executed. They can also be used to customize the model binding process for an action method.

 Action filters run after model binding has occurred, just before an action method executes. They also run after the action method has executed. They can be used to extract common code out of an action method to prevent duplication. 

 The Controller base class also implements IActionFilter and IAsyncActionFilter. They run at the start and end of the action filter pipeline, regardless of the ordering or scope of other action filters.

 Exception filters execute after action filters, when an action method has thrown an exception. They can be used to provide custom error handling specific to the action executed. 

 Generally, you should handle exceptions at the middleware level, but exception filters let you customize how you handle exceptions for specific actions or controllers.

 Result filters run just before and after an IActionResult is executed. You can use them to control how the action result is executed, or to completely change the action result that will be executed.

 You can use ServiceFilterAttribute and TypeFilterAttribute to allow dependency injection in your custom filters. ServiceFilterAttribute requires that you register your filter and all its dependencies with the DI container, whereas TypeFilterAttribute only requires that the filter’s dependencies have been registered

Rate limiting in asp.net core

 There are 4 rate limiting algorithms:

• Fixed window
• Sliding window
• Token bucket
• Concurrency

Fixed window : The AddFixedWindowLimiter method uses a fixed time window to limit requests. When the time window expires, a new time window starts and the request limit is reset.

below are steps to configure fixed window rate limiter

1. Add Rate Limiter:

       builder.Services.AddRateLimiter(_ => _

                .AddFixedWindowLimiter(policyName: fixedPolicy, options =>

                {

                    options.PermitLimit = myOptions.PermitLimit;//2, getting values from config

                    options.Window = TimeSpan.FromSeconds(myOptions.Window);//2000 

                    options.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;

                    options.QueueLimit = myOptions.QueueLimit;// 2

                    

                }      

             ));

2.      app.UseRateLimiter();

3. call RequireRateLimiting("policyname like fixed") either on minimal api endpoint or MapControllerwithDefaultRoute().

4. We can use [EnableRateLimiter] , [DisableRateLimiter] attributes if we don't want to configure rate limiter globally.

5 we can configure multiple ratelimiting policies on AddRateLimiter and we can use specific policy for specific controller/Action method.

concurrency limiter :

The concurrency limiter limits the number of concurrent requests. Each request reduces the concurrency limit by one. When a request completes, the limit is increased by one. Unlike the other requests limiters that limit the total number of requests for a specified period, the concurrency limiter limits only the number of concurrent requests and doesn't cap the number of requests in a time period

Distributed caching using Redis in asp.net core.

 To use Redis for distributed caching in ASP.Net core you need to follow below steps:

1. Need to add NuGet package "Microsoft.Extensions.Caching.StackExchangeRedis"
2. Need to configure Redis service via 

            builder.Services.AddStackExchangeRedisCache(option =>{
                string connection = builder.Configuration.GetConnectionString("redis")!;
                option.Configuration = connection; //< == provide connection string;               
            });

     3.configure redis connection in AppSettings.json

"ConnectionStrings": {

    "redis": "localhost:6379"

  }

      4.You need to inject IDistributedCache dependency in Constructor or endpoint.

IDistributedCache provides GetString("StringKey") and SetString("StringKey","StringValue") API, to set your object in Cache you need to serialize it.

app.MapGet("/weatherforecast", (HttpContext httpContext, IDistributedCache cache) =>

            {

                var strCachedForcast = cache.GetString("Forecast");

                if (string.IsNullOrEmpty(strCachedForcast))

                {

                   var cachedForecaste = Enumerable.Range(1, 5).Select(index =>

                       new WeatherForecast

                       {

                           Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),

                           TemperatureC = Random.Shared.Next(-20, 55),

                           Summary = summaries[Random.Shared.Next(summaries.Length)]

                       }) .ToArray();

                     strCachedForcast =  JsonSerializer.Serialize< WeatherForecast[]>(cachedForecaste );

                    cache.SetString("Forecast", strCachedForcast);

                }

              return  JsonSerializer.Deserialize<WeatherForecast[]>(strCachedForcast);             

            })

            .WithName("GetWeatherForecast")

            .WithOpenApi();  

Calling transient service in Singleton service

 If you will call transient service within singleton service, transient service will be treated as singleton service, i.e. the instance of transient service will be available till the lifetime of singleton service/application.

 public interface ISingleton

    {

        void SingltonMethod();

    }

    public class Singleton : ISingleton

    {

        public Singleton(ITransient trnasient)

        {

            Console.WriteLine("Singleton ctor called");

            Transient = trnasient;

        }

        public ITransient Transient { get; }

        public void SingltonMethod()

        {

            Console.WriteLine("Singleton Method");

          Console.WriteLine("  Transient instance Id :" +Transient.GetHashCode());

        }

    }

    public interface ITransient

    {

        void TransientMethod();

    }

    public class Transient : ITransient

    {

        public Transient()

        {

            Console.WriteLine("Transient ctor called");

        }

        public void TransientMethod()

        {

            Console.WriteLine("Transient Method");

        }

    }

    public interface ITransientA

    {

        void TransientMethod();

    }

    public class TransientA : ITransientA

    {

        private readonly ITransient trns;

        public TransientA()//(ITransient trns)

        {

            Console.WriteLine("TransientA ctor called");

            //this.trns = trns;

        }

        public void TransientMethod()

        {

            Console.WriteLine("Transient A Method");

            //trns.TransientMethod();

        }

    }

Service Registration:

          builder.Services.AddSingleton<ISingleton, Singleton>();

            builder.Services.AddTransient<ITransient, Transient>();

            builder.Services.AddTransient<ITransientA, TransientA>();

Service injection:

         app.MapGet("/", (ISingleton service,ITransient transient , ITransientA transientA) => {

                service.SingltonMethod();

                transientA.TransientMethod();

                Console.WriteLine("transientA hashcode :"+ transientA.GetHashCode());

                 /transient.TransientMethod();

                 Console.WriteLine("transient hashcode :" + transient.GetHashCode());

             });

Output:

Custom middleware before

Transient ctor called

Singleton ctor called

Transient ctor called

TransientA ctor called

Singleton Method

  Transient instance Id :39449526

Transient A Method

transientA hashcode :50346327

Transient Method

transient hashcode :50874780

Custom middleware After!

Custom middleware before

Transient ctor called

TransientA ctor called

Singleton Method

  Transient instance Id :39449526

Transient A Method

transientA hashcode :11404313

Transient Method

transient hashcode :64923656

Custom middleware After!

clearly, we can see that instance of transient dependency within singleton is same all the time, while in other injections we are getting new instance.

Difference between HttpPut and HttpPost method

 Although technically, we can create and update resource with both Put and Post methods but as per standard we should use Post method to create a new resource while we should use Put method to update existing resource.

There are few differences between these two methods:

1. While creating resource we don't have primary key of resource so in case of Post we don't have primary key in resource body but we have primary key of resource in case of Put.
2. URI used for PUT method directly identify resource to update, while we will get a new URI for newly create resource by POST method.
3. Most important difference between these two methods is PUT is idempotent means same request gives same response each time, but post can give different result.