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.
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.
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.
They do, and it's not so much about the overhead in terms of performance so much as the cognitive load of spreading out what would otherwise be a smaller/simpler codebase.
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.
The library's tagline says "Powerfully Simple. Blazingly Fast." So there. ::folds arms::
Joking aside, I do agree that ASP.NET Core is a behemoth. On .NET 9, I just now did `dotnet new webapi` followed by `dotnet publish --self-contained -p:PublishSingleFile=true` and the binary is 103MB. That would blow up the size of a mobile app considerably, just to listen to HTTP.
There a separate use case that SimpleW won't solve: When you're on a platform that .NET Core doesn't support, like Raspberry Pi Zero (armv7l). In this case all you have is the mono framework and binding to raw ports.
Did you try compiling all the test to native thru AoT? There are probably some optimizations to improve the Kestrel score by altering the config, or maybe changing how the API is written:
As a general web server, I think I'd always go for Kestrel over this, but as another poster said, if you're trying to add an endpoint to some desktop application, this would be perfect.
Most of that is runtime taking up space. So yes, baseline is 103MB but outside that, it's not likely to balloon too much past assets. Compared to Python/Node/Java/Ruby containers I see as SRE, 103MB is god send.
> On .NET 9, I just now did `dotnet new webapi` followed by `dotnet publish --self-contained -p:PublishSingleFile=true` and the binary is 103MB.
I've just tried the same, but with native-aot (build to native code). On Windows it was around 10mb, including routing, JSON serialization and openapi support. Startup is nearly instant.
If you include the dotnet runtime it's much bigger, but that's expected.
Edit: built with dotnet publish -r win-x64 -c Release /p:PublishAot=true /p:PublishTrimmed=true /p:PublishSingleFile=true
Sometimes. It's usually a lot bigger than that the moment you pull in any simple dependencies. Also the CLR memory overhead is horrible. Our .Net guys have serious problems with startup time (JIT) and initialy latency on .Net Core so I don't trust the fast claim. And no you can't just AOT everything.
We moved a couple of critical services over to Go because of those two issues and it turned a few heads.
We are fairly high traffic. Deployments, even rolling, can and do cause fairly noticeable latency spikes and side effects like upstream services having to queue requests, pool escalations, all sorts. Warming stuff up before first hit is a complete bitch on top of that.
I notice Apple had similar problems and moved some of their back end to Swift from JVM recently. There was a post on here.
Yep, downside of virtual language like that. Upside of Java/.Net is their extensive libraries and really good developer experience. Just like Golang GC caused Discord endless amount of headaches in some of their routes.
I have some heavy ASP.Net stuff too, yep, we have to prewarm it before putting into production.
I hate when someone's software advertises itself as 'blazingly fast' and then provides NO DATA to back up the claim. It's possible that it really is blazingly fast, but to make the claim and provide no data is sad. In God we trust - all others please bring data.
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 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 factory methods for service registration to use an external `IServiceProvider`.
For console applications, I would recommend using `Host.CreateEmptyApplicationBuilder` [2]. Makes it a lot easier to configure services for Console applications. It also handles `IHostApplicationLifetime`s.
Wow I did not know that, I was always under the assumption that I needed to have a project using the Microsoft.NET.Sdk.Web for anything Web as its base. Thanks for the info!
It used to be much more modular back in dotnet core 2.x. It was just too complex for most people to wire up everything themselves. You needed to install a lot of nuget packages, add a lot of middlewares. In the end 95% of the projects added everything anyway, but always with some little mistakes and weird errors.
Starting with 3.0 (or 5.0?) they ditched the Startup class and just added in everything by default. Much easier for the regular web application. The modular approach is still everywhere though. You can just pick the components you need, most of them also run without DI, it's just a bit of a hassle to manage all those dependencies manually.
FrameworkReference enables other cursed combinations, too. You can use WinForms/WPF in an ASP.NET project with a FrameworkReference to Microsoft.WindowsDesktop.App. Finding a use case for this is left as an exercise for the reader.
I think you can just pick the components you really need via nuget reference. And start/stop the web server as you 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().
Yes, in my opinion. But also objectively it's really good for many things.
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!).
The webserver variability isn't really so wide because the in the box offering since Core has been pretty good, flexible and works for most use cases. And while I really like FastEndpoints a lot over the minimal api stuff, even that is pretty straight forward.
It's not my favorite, it starts slow and I'd rather go up to JS/TS for scripting flexibility or down to Rust for really lightweight performance with fast startups. It's one of the better all-around options though. I'd rather use it over Java every day of the week and there are adapters for most things you'd ever need to communicate with.
> those opinions most sense for VAST majority of their users
I have a much more nuanced view.
I think that ASP.Net is the de facto standard for being backed by Microsoft since many years. From the gold time when ASP means IIS to now when Kestrel was cannibalized by Microsoft.
As a developer, working with the most widely used stack guarantees that these choices won’t be questioned in critical situations. I’m not saying Kestrel is bad, but it doesn’t automatically fit every scenario.
- 15 years ago, there were Apache or IIS.
- Then nginx changes the game and kicks their ass
- Then webserver starts being written into script langage for better integration (Ruby, Python), no more CGI and nginx as reverse
- Then node changes the game
- Now : caddy and other alternatives... but still not web server in PHP (troll inside)
I see a pattern to not believe aspnetcore is the only one and the best.
seems like the author didn't like the obvious or alternative solutions out there, and went and created one of his own.
i know some people who use their own web server, this is an on going adventure for sure.
In total. Just compare different web frameworks by performance, flexibility, features and so on. Whatever you compare, ASP.NET Core will probably end up in the top 20%.
People (particularly, HN) still associate it with the old .NET framework days and it being tied to Microsoft, Windows Server, etc.
.NET has had a hard time shaking off that old stigma, and to be fair, by the time it was really good, a lot of places already moved on to other tech (in particular, Go) .NET missed its window to escape the enterprise and despite being great, will probably never be seen as sexy.
I love it though. It's by far one of the most productive frameworks, and C# is pleasant to work with, and F# even more so.
Yeah it's lived experience vs perception for me. .NET developers have always, ALWAYS loved to tout how great things are but there's a reason anyone even slightly outside the MS-sphere simply chooses not to use it.
Because it's not that great, really.
The performance isn't that great in real-world scenarios (remember when they had to lie, in that "one" incident)? Even today the tests look NOTHING like actual idiomiatic .NET code.
Secondly, .NET developers tend to target a particular set of DevEx that I don't personally understand but that's not the problem, the problem is the DevEx has end-user effects; they simply just don't give a shit.
Anything past a simple B2B crud app in .NET is basically an uphill battle in real companies. It never works out, it's always more complicated than it needs to be.
But hey, no one gets fired for choosing MS. So here we are.
If you drop the religious zealotry, there's simply not a lot left.
It's been really great since I've been able to develop on Windows and deploy to a cheap Linux VM instead of having to deal with IIS. Game-changing for me.
The old asp.net was not only horrible in regard of deployment (iis/windows). The whole thing was a mess. It might've been innovative around 2005, but it was completely scrapped in ~2016 for a good reason.
ASP.NET Core comes with its own built-in web server named Kestrel, which is very highly optimized. On most projects, I use it totally bare-metal, though I figure most run it behind a reverse proxy like nginx or yarp.
YARP is (Yet Another) Reverse Proxy, and Aspire is in a similar space to Testcontainers - i.e. orchestration of multiple executables for test (and other things). No it's not an alternative to Kestrel.
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".
> 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.
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.