61–70 of 80 posts
Earlier quoted context omitted.
There's also Fast Endpoints[1], which Kind of the best of both worlds, minimal-API and REPR. 1: https://fast-endpoints.com/
Came to mention the same... really like FastEndpoints myself a lot.
Not sure about this one. It's based on NetCoreServer which is great but it's definitely not something I'd be comfortable putting into production over kestrel or IIS. From a performance standpoint, it is very difficult to beat kestrel now. If you don't want all the fancy Microsoft bullshit (I certainly don't), use the minimal APIs and map out routes to lightweight HttpContext handlers.
There's also Fast Endpoints[1], which Kind of the best of both worlds, minimal-API and REPR. 1: https://fast-endpoints.com/
thank for the pointer !
The syntax seems cool and comprehensive, i like it.
I made some test and like its name, it is very fast : performances are closed to SimpleW, just a little bellow. But its memory footprint is the half, so i'm impressed. I will check the code, sure there are interesting things into.
The documentation on VitePress looks cool. I didn't think there was such a theme there.
The default template is great and everything in VitePress has been thinking to create documentation. Very nice project.
Earlier quoted context omitted.
Have you tried Kestrel, YARP and Aspire?
I'm not familiar with YARP, but isn't Aspire still using Kestral? I think of Aspire as more of a code driven, flexible Docker-Compose alternative.
These are three different tools that do different things. The point is that these are better examples of the "modern MS ASP Infra" space than "nginx, iis".
Earlier quoted context omitted.
Came to mention the same... really like FastEndpoints myself a lot.
Same although Minimal APIs are slowly getting there. In dotnet 10 we will finally get validation.
Edit: Of course, Aspire definitely looks interesting for more complex needs.
But why? ASP.NET Core is one of the best web frameworks, extremely modular and flexible. It's low level components (http server, routing) can be used as a foundation for new web frameworks.
One of the use cases that stands out to me is dropping an API into a console application without having to use a different project. With ASP.NET I have to set up a new project, use a different SDK and then re-register all my services in its service collection. It looks like this one is bringing it closer to how it's done in Go which I personally really like.
The full asp.net out-of-the-box experience is tailored to the most common use case, which is a plain web service.
I think you can even run the Kestrel HTTP server without all the asp.net pipelines, infrastructure and without dependency injection.
Also the common WebApplication.CreateBuilder() includes a lot of default configuration (batteries included), there is also CreateSlimBuilder() and CreateEmptyBuilder().
But why? ASP.NET Core is one of the best web frameworks, extremely modular and flexible. It's low level components (http server, routing) can be used as a foundation for new web frameworks.
> ASP.NET Core is one of the best web frameworks In your opinion. Not everyone is of the same mind when it comes to software design. Sometimes the motivations are different. As a community we should encourage those looking to find their own path. We become myopic otherwise.
That's the reason I asked the question "why?". It's probably much slower (asp.net got performance/memory optimized to a ridiculous extent), and might contain dangerous vulnerabilities (creating a secure http server is hard!).
Earlier quoted context omitted.
A web server should never be directly exposed to the Internet, provided you care about the web server host or what's behind it.
> A web server should never be directly exposed to the Internet That's what web servers are made for, no? Like Apache, Nginx etc. I mean, you could certainly put HAProxy in front but you'd need a good reason to do this.
More often than not, for any serious application backend, you probably want a web application firewall (WAF) in front of it and SSL termination upstream of the web server.
Earlier quoted context omitted.
Same although Minimal APIs are slowly getting there. In dotnet 10 we will finally get validation.
Fair enough... I'd probably stick to Minimal APIs if there were fewer than 5-10 routes in a smaller service. But, with the startup and runtime overhead of .Net, I'm inclined to prefer more monolithic approaches for most general use. Just without weighing it down with a lot of heavy handed enterprisey abstractions. Edit: Of course, Aspire definitely looks interesting for more complex needs.
Earlier quoted context omitted.
One of the use cases that stands out to me is dropping an API into a console application without having to use a different project. With ASP.NET I have to set up a new project, use a different SDK and then re-register all my services in its service collection. It looks like this one is bringing it closer to how it's done in Go which I personally really like.
You shouldn't have to change the SDK. You can create a class library ASP.NET Core Server by using a FrameworkReference [1]. I can't remember the library, but there was one that had its own `IHostedService` with its own embedded ASP.NET Core Server startup within it. If your `WebApplication` requires services, of course you're going to have to register its dependencies on its `IServiceCollection`. Though, you can use…