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.
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.
> 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
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.
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.
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.
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.
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.
> 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.
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".
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/
> There's also Fast Endpoints[1]
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.
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.
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.
AFAIK FastEndpoints uses Minimal APIs... so wouldn't the overhead be similar?
For the uninitiated, what's wrong with NetCoreServer?
I really wish that Kestrel was available as a standalone library. Kind of like Jetty on the JVM.
I wonder. Is this one meant to deal with raw internet traffic or sit behind an ingress e.g. IIS?
minimal APIs is microsoft bullshit
also what does performance matter on webservers
Performance matters to me. I'm on a budget, running tiny Hetzner boxes. Every cycle counts.
> minimal APIs is microsoft bullshit
Agreed, but it is the least smelly pile they have on offer.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
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.
I agree that ASP.NET Core is fantastic and it doesn’t give you many reasons to look elsewhere.
That said I think some diversity / competition / cross-pollination should be welcomed in the .NET space.
Not a fair comparison but I’m glad Avalonia exists despite WPF, for example.
There used to be Nancy, but it got pointless to compete with asp.net core.
Avalonia is cross plateform unlike WPF.
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.
> The library's tagline says "Powerfully Simple. Blazingly Fast."
> Joking aside
author here.
I agree with your remark ^^
Each time i read some news about a new framework with tag "blazingly fast", i'm thinking "lol".
So i had to resist to the temptation... And finaly when doing a small benchmark, performances were not bad at all (https://stratdev3.github.io/SimpleW/guide/performances.html) and i let the "clickbait" title.
My targets are small to medium traffic and embeded devices (dotnet/android).
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:
app.MapGet("/api/test/hello", () => "Hello World!");
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.
> There are probably some optimizations to improve the Kestrel
You're right.
To be fair, i have to run many other benchmarks including one with the best recommanded optimizations for each projects.
a little time consuming but definetely on my todo list.
> 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
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.
I think you are expecting too much here.
Enable trimming
Simple claim with a complex story.
I thought about mentioning AOT and trimming, but my comment was already long.
AOT in ASP.NET is still a moonshot in most cases, and a non-starter in existing web apps due to dependencies not supporting AOT.
Worth mentioning that as of .NET 9 AOT is not supported on Android.
Soo many dependencies do not support AOT.
And AoT.
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.
> I hate when someone's software advertises itself as 'blazingly fast' and then provides NO DATA to back up the claim
agree, that's why there is a performance benchmark at https://stratdev3.github.io/SimpleW/guide/performances.html with code as you can reproduce at your own.
i'm adding other tests, more complete than the hello world one.
Cool! Please add link to that page from your github project's main page.
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.
Curious what the use-case is where JIT latency is an issue for a http service?
Probably Serverless functions, which is a use case where standard ASP.NET Core is not particularly good.
I'd blame Serverless more than ASP.NET Core for the bad performance in that case though.
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.
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 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.
[1] https://learn.microsoft.com/en-us/aspnet/core/fundamentals/t...
[2] https://gist.github.com/pethin/7e5edd7614ff2f51c06c086e1bc7c...
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().
> 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.
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!).
author here.
I wanted to start with something small where I could read or write the code in a reasonable amount of time.
My usage was, and still is, for low traffic. I don't intend to replace the Kestrel beast.
Just a framework you can quickly understand without being lost in documentation once you want to custom a part.
> ASP.NET Core is one of the best web frameworks
I don't think so.
The fact is there are very few dotnet web servers. ASP.NET Core is supported by the owner of the dotnet langage who is also the M of the GAFAM.
There is some place in the ecosystem for other alternatives
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.
>The fact is there are very few dotnet web servers.
SRE here, very few because Microsoft is strongly opinionated with ASP.Net and those opinions most sense for VAST majority of their users.
> 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.
I was wondering samething. But then I saw that it has some built-in capabilities for WebSockets and OpenTelemetry.
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.
no its not. We always can use alternatives
>ASP.NET Core is one of the best web frameworks
...based on what?
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%.
crazy how people just dont want to believe it, but its really really good
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.
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.
It definitely turned into a mess. You're right that post-2016 ASP is when it finally found its way.
Does this mean a developer doesn't have to install nginx or iis ?
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.
This has been the case for years
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
No modern dotnet web framework requires nginx or iis.
> Does this mean a developer doesn't have to install nginx or iis ?
author here.
You don't have to keep it behind a reverse proxy like nginx.
But you can, especially if you have multiple APIs and you want to keep thing separated for security reason.
Example :
nginx:443 (reverse proxy, domain name routing)
|
|-> website1:8081 - docker container with SimpleW
|-> website2:8082 - docker container with SimpleW
|
...
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.
This is not the case for the modern Internet.
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.
And also a reverse proxy / Load balancer in front of multiple Webserver instances.
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.
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".
At a quick glance it looks much simpler than e.g. Kestrel, which I found pretty confusing to get running.
author here.
that's the reason why i start the project. I had time and wanted something simple as my needs.
The documentation on VitePress looks cool. I didn't think there was such a theme there.
VitePress saved my day.
The default template is great and everything in VitePress has been thinking to create documentation. Very nice project.