I've hedged the stability risk by using the narrowest possible slice of the framework.

With enough experience you can accomplish pretty much everything using just the minimal API and router. HttpContext is the heart of AspNetCore. If you can get your hands on instances of it within the appropriate application context, you can do anything you need to. Everything else is dependent upon this. The chances that HttpContext can be screwed with are very, very low. There are billions of dollars riding on the fact that this type & API remains stable for the next decade+.

▲ jtbaker 2 days ago | parent [-]

do you still use the framework's DI pattern with this approach? I have an older school .NET app I work on (still Core) sometimes and haven't gotten much experience with the minimal APIs, although it looks attractive as someone that prefers lower level routers.

	▲	bob1029 2 days ago \| parent [-]
		I use the AddService() method to inject a things on occasion but its not used heavily. For lightweight apps I'll spin up things like a shared SQLiteConnection and inject it for all resources to use. The DI pattern is simple & clean at this scale. In my top-level program I define my routes like: `app.Map("/", Home.HandleRequest); app.Map("/login", Login.HandleRequest); app.Map("/account/new", NewAccount.HandleRequest); app.Map("/{owner}", OwnerHome.HandleRequest);` And then I have HandleRequest implementations like: `static async Task HandleRequest(HttpContext context, SQLiteConnection sql) static async Task HandleRequest(HttpContext context, SQLiteConnection sql, string owner) etc...` The actual HandleRequest() method can do anything, including concerns like directly accepting and handling web socket connections.