Add global rate limiting sample and much more

[64J0]

Description

Warning

This is just experimental. To be honest I don't like this configuration that demands an empty list. I'll ask for more opinions before making this huge change to the Giraffe codebase.

With this PR, I'm:

• Adding a global rate limiting sample;
• Updating the code to work only with .NET 8 (due to the ASP.NET extensions);
• Adding the possibility to configure "ASP.NET extensions", which are middlewares like CacheOutput and RateLimiting, per route;
• Adding a new rate limiting sample that deals with this mechanism.

TODO:

• Filter repeated "ASP.NET extensions" to use the last value only;
• Update docs;
• Q: Is it possible to add OpenApi native configuration from ASP.NET?;
• Add automated tests.

How to test

Check the instructions at the sample's README.md.

Related issues

Related to #618.

[nojaf]

One user on #618 requesting a feature is typically not a strong enough reason to make drastic changes to the public API. I would only consider it if the demand were significantly higher.

As a workaround, you can use:

    type Endpoint =
        | SimpleEndpoint of HttpVerb * RouteTemplate * HttpHandler * ConfigureEndpoint
        | TemplateEndpoint of
            HttpVerb *
            RouteTemplate *
            RouteTemplateMappings *
            (obj -> HttpHandler) *
            ConfigureEndpoint
        | NestedEndpoint of RouteTemplate * Endpoint list * ConfigureEndpoint
        | MultiEndpoint of Endpoint list
#if NET8_0
        | NewThingWithRateLimiting of blah
#endif

Additionally, consider introducing a similar DSL function wrapped in #if NET8_0. I understand this may complicate things, but it's a better approach than altering the API on a whim.

Alternatively, you could release another major version, but be cautious not to have too many, as end-users will always have upgrade work on their side.

On a practical note, launching another major version to drop support for net6.0 after the release of net9.0 in November seems reasonable. Ultimately, I believe this change should be communicated more clearly and not be a side effect of a PR.

[nojaf]

This is massive breaking change is it not?
Is means every existing code with route would break.

I'd go for the following:

let routeWithExtensions (path: string) (aspNetExtensions: AspNetExtension list) (handler: HttpHandler) : Endpoint = SimpleEndpoint(HttpVerb.NotSpecified, path, handler, id, aspNetExtensions)

let route (path: string) (handler: HttpHandler) : Endpoint = routeWithExtensions(path, [], handler)

[64J0]

Indeed, it looks a better path to go

[nojaf]

Another breaking change here.

[nojaf]

Updating analyzers is best handled in a separate PR, to be honest. It can make the current PR noisy, and I generally find that smaller PRs focusing on one thing are easier to review.

[ebellani]

👍

[64J0]

I'm closing this PR in favor of more succinct ones, which I'll open later, tackling specific points of the ideas presented here.

[64J0]

Something that has potential 🤔

This function that currently uses the id function has this type:

type ConfigureEndpoint = IEndpointConventionBuilder -> IEndpointConventionBuilder

I don't know much about it, but maybe we can use it instead of this custom wrapper for Asp.Net extensions https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.iendpointconventionbuilder?view=aspnetcore-9.0