Lecture thumbnail 0:00 / 0:00 If you think of writing the endpoint filter code in a separate file, then here is the solution.

You will create a separate custom class that implements IEndpointFilter

and implement a method called InvokeAsync. So that contains your actual logic of your

before logic as well as after logic. And in between, you will invoke the

next delegate that invokes the subsequent filter or the endpoint request delegate itself

as we have seen in the last lecture. Let me show that practically.

I would like to convert the existing code into EndpointFilter class.

So that as a benefit, the code in this particular file doesn’t increase even though you have so

many number of endpoints. So it’s all about how do you organize your code and reuse the code if

required. Because you can apply the same endpoint filter to more than one endpoint if it is created

as a separate class. In your solution explorer, right click on the project. Create a new folder.

Folder name is EndpointFilters. Right click on that folder. Add new item. Select class.

And the file name is MyCustomEndpointFilter. The class name can be anything of course.

Add it. So this is your custom class. And in order to make it as endpoint filter,

implement an interface called IEndpointFilter. And implement the same interface.

So you have invokeAsync method. It should return the value task.

Means it is a task that can return the request delegate or subsequent filter.

Because at the end of the method, we have to return the next delegate call.

First, invoke the next delegate. Make it as asynchronous method. So you can use await keyword.

Supply the context as argument. As you know, it invokes the subsequent filter, if any.

But what if there is no another filter applied for the same endpoint?

In that case, it invokes the request delegate of the same endpoint.

And receive the return value of the same. And at the end of the code, return the same.

Just like what we did in the last lecture.

Now above, you can add your before logic. And here after logic.

Optionally, since it is a separate class, you can inject any other services through

constructor injection. For example, I would like to inject ILogger. We have not configured any

separate logging provider in this project. So the built-in ASP.NET core logging works.

This is the private field of logger type. And inject the same service through constructor.

OK, we have injected the logger. Add some logic in the before logic as well as after logic.

OK, this is before logic. And one more for after logic.

So add a breakpoint in this invokeAsync method in both before logic as well as after logic.

And now, how do you apply the same endpoint filter to the existing endpoint?

So switch back to the map group file. Here you can use a method called addEndpointFilter of.

You can supply your class name as a generic parameter.

What is our custom class name? That is CustomEndpointFilter, right?

This is how you add the custom endpoint filter to the existing endpoint.

This is a delegate as endpoint filter. And this is a class as endpoint filter.

Both work in the same way. The concept of before logic and after logic doesn’t change.

OK, now let us try to run the application.

Make sure you have added breakpoints in all the endpoint filters.

Including the custom class as well as custom delegate.

Run the application now. And we are making a request.

So the same URL, products and post request with request body.

Send a request.

Now it first executes the before logic of the custom filter.

Because when more than one filter is applied, it executes the filters in the order of FIFO.

First in first out. Here what is the first filter that we have applied?

That is CustomEndpointFilter. So it executes first.

So currently we are in the CustomEndpointFilter before logic.

And after this log statement. Here is the point.

Here we are calling the subsequent one. And what is the subsequent delegate here?

Either it is filter or request delegate of endpoint?

Yes, we have second filter, right?

So this next delegate calls the delegate of the subsequent endpoint filter.

That we have created in the last lecture.

So let’s click on continue. Now we are in the before logic of the second filter.

It holds the execution of the first filter there.

So we are executing the second filter here.

And after validating your product as we have done in the last lecture.

In case of no errors, we are calling the next.

So it invokes the subsequent filter.

But in this case, there is no any other subsequent endpoint filter.

In this case, it executes the endpoint request delegate.

Since there are no more filters in this pipeline.

So now we are on the actual request delegate of endpoint.

We will add the product object into the products collection.

And then return the result.

But the story doesn’t end here.

It executes the after logic also, right?

In this case, it executes last in first out.

That is outermost first and then innermost.

So it executes after logic of the second filter.

I mean, it executes the after logic of the filter that is added later.

So after completion of this after logic.

Then it comes back to the after logic of the first filter.

That is custom endpoint filter.

See here.

We are on the first filter.

That is custom endpoint filter.

And after completion of this after logic.

And that is the end of the pipeline.

So the final response sent to the browser.

In this way it works.

So in general world practice.

You don’t have any reason to create more than one filter.

Maximum you will be creating one or two endpoint filters.

That could be enough.

If you don’t want to reuse your endpoint filter.

It is okay to create the same as a simple delegate.

As we have done in the last lecture.

But in case if you want to better organize the code.

Or reuse the endpoint filter code.

Then creating the same as a separate class like this.

Will be the better choice.

At your practice time you try to do one thing.

Whatever the validation code that we have done in this endpoint filter.

Shift the same code into the custom endpoint filter class.

I mean cut and paste the same code here.

That could be enough.

Try it at your practice time.

Okay finally this is the way how do you create and apply the endpoint filters.

In ASP.NET Core minimal API.

And these are the updates in minimal API as of this moment.

If any new features have been added in the minimal API.

I will make and add relevant lectures in the same section.