FastEndpoints VS FluentValidation

Bonus Time! In addition to the Microsoft-supported methods above, many community frameworks exist for building APIs with .NET. FastEndpoints is an option I found recently that seems very promising. With performance benchmarks that put them on par with Minimal API, they are firmly ahead of Controller-based APIs.

Have you had a look at FastEndpoints yet? Any thoughts?

And yet, all Microsoft's demos for the upcoming changes for Blazor in .NET 8 (like SSR) has been a public facing recipe site (e.g. https://www.youtube.com/watch?v=QD2-DwuOfKM). I'd say this is a very similar use case as the Microsoft Store.

I love .NET and ASP.NET Core, but I use it purely for backend. And even there, I use 3rd party libraries like Fast Endpoints (https://fast-endpoints.com/). Microsoft keeps bringing in new technologies and effectively abandoning the ones that fall out of favour (look at the progression from MVC -> Razor Pages -> Blazor). I do not blame the Microsoft Store team for not trusting the .NET team to not simply abandon Blazor as well somewhere down the line and instead opt for other technologies for the front-end.

I also find a very similar framework in .NET "Fast Endpoints"

I gave it a go and I was impressed how easy and fast it was to set it all up. Since I'm not a big fan of REPR pattern almost all my projects are using CQRS pattern with a help of MediatR ](https://github.com/jbogard/MediatR) I immediately started going over something similar that Fast Endpoints offer which is a command bus.

Ive personally been using FastEndpoints which is a community built thing on top of minimal apis - https://fast-endpoints.com/

I've just started to use a similar thing, and it's so much better than controllers - https://fast-endpoints.com/

Sort of minimal but check out FastEndpoint. https://fast-endpoints.com/

Here is an example of Command handler with built-in Fluent Validation and fire and forget style:

There is an RFC called Problem Details (RFC7807) that standardizes how an error in an API should be responded to for the client. If you use Fluent validation, you may have noticed that the response is within this pattern.

here we're defining the input validation requirements using fluent validation rules. let's see what happens when the user input doesn't meet the above criteria. execute the same request in swagger with the following incorrect json content:

I remember FluentValidation being a nice library for this type of stuff.

Literally the code example in the front page: https://fluentvalidation.net/

https://www.nuget.org/packages/Newtonsoft.Json/ https://www.nuget.org/packages/AutoMapper/ https://www.nuget.org/packages/Dapper/ https://www.nuget.org/packages/FluentValidation/ https://www.nuget.org/packages/FluentAssertions/ https://www.nuget.org/packages/NUnit/ https://www.nuget.org/packages/xunit/ https://www.nuget.org/packages/YamlDotNet/ https://www.nuget.org/packages/Moq/ That is simply not true. Mature c# projects purposely maintain no downstream dependencies and is they do, it's to a major reputable lib. See for yourself - these are staple third party packages commonly used. Anything dependency starting with System or NETStandard is Microsoft maintained.

FluentValidator for validating and authorising certain fields.

Now that we know the importance of providing users with enough information about their requests and how it was processed, let’s focus on how we can configure our API to help us do that.One aspect of such meaningful experience is Request Validation (400 Error Range). For that purpose I am using a library called Fluent Validation.