As an alternative to using additional framework layers, I'd recommend spending an afternoon familiarizing yourself with AspNetCore middleware - and HttpContext in particular. Getting at the raw primitives can allow for you to throw away a lot of confusing boilerplate.<p>Once you learn that everything that happens in the most complicated corners of web apps is ultimately dancing on top of HttpContext, you can <i>dramatically</i> simplify your life. Even things like web sockets and 3rd party auth are just a handful of lines on top.<p>These abstractions are <i>not scary</i> to use. The Microsoft documentation is really poor with regard to guiding developers towards these simpler approaches. It's fairly obvious that they want you deep in the Azure complexity matrix. The only exception I have found to this perception is noted below [0].<p>Mastery here means you can avoid pulling down vendors' interpretations of how your entire application should be written. You can write whatever middleware per their specifications and make it fit your patterns perfectly. I recall what it was like allowing my auth vendor's ham-fisted libraries drive much of how my web app and DI had to be structured.<p>[0]: <a href="https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-8.0" rel="nofollow">https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...</a>
I appears that this is using HttpListener to implement the HTTP protocol:<p><a href="https://github.com/sisk-http/core/blob/main/src/Http/HttpServer.cs#L35">https://github.com/sisk-http/core/blob/main/src/Http/HttpSer...</a><p>HttpListener, while not deprecated, is frozen and not taking new features. For example, it does not support HTTP 2. It might not be as high performance as Kestrel (the default web server in ASP.NET Core).<p><a href="https://github.com/dotnet/runtime/issues/63941#issuecomment-1205259894">https://github.com/dotnet/runtime/issues/63941#issuecomment-...</a><p>So the authors of the framework might want to consider longer term whether layering onto of Kestrel or some other HTTP server implementation may make more sense.
I’d like to support this, truly I do—I’m a .net fan.<p>But I read the docs. Sisk is supposed to be simple. But the code samples are nearly the same as ASP.NET minimal APIs. Can you clarify why Sisk is better than out of the box .NET?
I remember way back (10? years) a library called Suave, a from scratch Web Server that was fun to work with (although never very high performance). I believe the original developer eventually kind of abandoned it because he felt he was treated poorly by the community (not sure, memory of this is a bit hazy). It's a real shame honestly, because it feels like all the novel F# stuff just got abandoned over time. This has a similar feel (not the code style, but just the intent). Dotnet needs a lot more goofy/unique libraries in general. Otherwise Microsoft pushes a monoculture and nothing good ever happens.
Dotnet is crying out for a lightweight front end for desktop and mobile.... But not a new backend??? That's already sooo good. Strange choice to add to the ecosystem.
What are the use cases for going with this framework over something like ASP.NET Core Minimal APIs? <a href="https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-8.0" rel="nofollow">https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...</a>
people like to shit on node.js / express.js but it changed the game on what lightweight server-side frameworks could be.<p>now everything follows the express pattern because it's explicit and simple.