.NET 7 Features - Part 2

Continuous to m previous article (.Net 7 Features-Part 1), this article have many more new features and improvements Microsoft has done with .Net 7.

As we must be knowing, .Net 7 already launched recently for public use and most of us will be existed to start upgrading existing .net projects to .Net 7 or create new project/service into .Net 7 and for that, it is require to have new features and improvements understanding. So here you go…

• HTTP/2 performance improvements

ASP.NET Core apps with busy HTTP/2 connections will experience reduced CPU usage and higher throughput.

HTTP/2 allows up to 100 requests to run on a TCP connection in parallel. This is called multiplexing. It’s a powerful feature but makes HTTP/2 complex to implement. Before HTTP/2 multiplexing in Kestrel relied on C#’s lock keyword to control which request could write to the TCP connection. While lock is a simple solution to writing safe multi-threading code, it’s inefficient under high thread contention. Threads fighting over the lock waste CPU resources that could be used for other work.

A thread-safe-queue replaces the write lock. Instead of fighting over who gets to use the write lock, requests now queue up in an orderly line, and a dedicated consumer processes them. Previously wasted CPU resources are available to the rest of the app.

These improvements are visible in gRPC, a popular RPC framework that uses HTTP/2

• Typed results for minimal APIs. Compare response type with Unit Test.

With .net 6, IResult interface was introduced to represent values returned from minimal APIs.

The IResult implementing framework types returned from these methods were internal however, making it difficult to verify the specific IResult type being returned from methods in a unit test.

In .NET 7 the types implementing IResult are public, allowing for type assertions when testing.

For demo, I am created one endpoint which return list of student info and with my unit test case I want to check the return type.

API:

Unit test case, where I am checking the return type as list of student info class:

• Swagger OpenApi self describing response type documentation with Minimal Api:

If your API return IResult response, then by default response schema/sample does not reflect on your swagger page but to enable that, you need produce explicitly your response type with endpoint:

Demo: continue to previous example code base:

• Return multiple result types from minimal APIs

Now you could return multiple response/result type with your API:

Demo: continue to previous example code base:

API:

Result:

• Map Group: helps organize groups of endpoints with a common prefix

Creating group of same APIs together

Mapping with map group along with tag as title of api group and base route:

As a result, all put into one group on swagger with tag as title of your api group:

• Top level programming made as optional now. So while creating project you can choose either top level programming or earlier format as using Main function:

By default, when you create project in .net 6 or 7, it will give you top level programming standard, where you will not see Main method.

So to get old structure as Main method, if you are creating project using dotnet command, then use like below:

> dotnet new web --use-program-main

With visual studio, you can use checkbox during project creation:

• Rate limiting with .net core

1. Fixed rate limit: This is used when you want to process fixed no. of request within defined time period/window,  like process only 2 request at every 10 second.
2. Token rate limit: This is used when you want to process request as per no. of token/requests available in limit bucket, so you intially allocate no. of requests/token into limit bucket and then you can keep adding no. of new request/token into limit bucket and then whenever request comes in, if limit bucket left with token/requests, it will process.
3. Concurrent /Concurrency rate limit: This is more useful in real world scenarios where, you want to process only specific number of requests at a time. Like I want to process only 1 requests at a time and rest should be rejected with error code 429. 

Demo: Refer below screenshot with Minimal API,

1. I have configured all three rate limit rule i.e. "fixed", "token", "concurrency" and then
2. used rate limit
3. Created three endpoint to test all three rate limit rule.

Jmeter test report sample of "concurrency" rate limit, where if you see as per rule, I have allowed to process max 1 request at a time, so when I am sending 2 request as infinite, then, some of them getting process and some of rejected.

Same if you want to apply with rest(mvc pattern) API then, rate limit configuration and use as you have done above with program.cs will remain same except how to apply with endpoint. So with rest mvc pattern api, you need to use attribute either on controller level or action level by passing rate limit policy name you want to apply:

Example:

[EnableRateLimiting("fixed")]

Public class HomeController: Controller{ }

When you apply it on controller level and want to disable for specific endpoint/action, then use below attribute on that specific action:

[DisableRateLimiting]

Public ActionResult NoLimitApiTest() { return response; }

Same you can apply for vpc razor pages as well and you can also setup/use fallback function/process on rejection like when request rejected due to rate limit reached to threshold, then you want to call any fallback function/process. You can also setup GlobalLimiter that is applied to all requests. The global limiter will be executed first, followed by the endpoint-specific limiter, if one exists. Refer below link for details for all such scenarios: https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?preserve-view=true&view=aspnetcore-7.0

• Output cache

You want cache your api response. Like you may have situations where your api response is almost static and instead of doing every time your api code execution, it should use cache data to return which was stored at first time.