IResult endpoint configuration/overloads?

[WorldMaker]

Hello, I used Oxpecker for the first time a bit okay for a test project. I've been thinking about the API versus raw ASP.NET Minimal API and feel like there might be an efficiency gain using IResult more directly as an explicit output type in Endpoint configuration. (More specifically that Task<IResult> is a potentially more useful return type for an endpoint than unit Task.)

A lot of the current handlers and how much sample code uses manual ctx.Write calls remind of something I feel that I see a lot in regular ASP.NET binding, like a fallback to imperative patterns in the middle of something that could be purely function. But in ASP.NET Minimal API when you focus in on returning IResult or IResult<'T> everywhere and especially in using the TypedResult family things like OpenAPI/Swagger documentation starts to be a whole lot more self-documenting and endpoints start feeling a lot more like pure functions: take in an input and return an output.

IResult and its family is a lot of complex machinery, but embracing it offers functional programming options that I think make for easier to unit test endpoints.

(The possible height of my functional programming in Minimal API so far was building an IResult wrapper for LanguageExt Aff<T> to be a tiny imperative shell for a larger functional core in C#. Not directly applicable, but perhaps and interesting illustration both why ASP.NET's IResult family seems so complex and also what great functional programming powers you can build with it.)

Just thought I'd throw the idea at the wall, see if it sticks or resonates.

[Lanayx]

@WorldMaker Hello, thank you for your input. Here are some of my thoughts.

Conceptually IResult is no different than EndpointHandler, it's just an object with one method vs function, that's why conversion between them is so trivial. At the same time, combining functions feels more functional than combining objects (which is actually decorator pattern from OOP), so I'm can't agree with the argument that IResult is more functional.

The concept of Handler was not invented in Oxpecker and is taken from its predecessor, Giraffe (and there it was taken from Suave). Over they years it was generally accepted as a convenient abstraction, allowing combining handlers and middlewares in a functional style.

At the same time, being functional has never been Oxpecker's goal. It's main goal was to take successful and well-known Giraffe's API and fix its main issues and pain points, providing as easy to use API as possible. Another Oxpecker's goal is to be one of the fastest .NET web frameworks (at the very least, faster than Minimal API), and using TypedResult brings certain performance penalty, so it is not regarded as a desired default.

OpenAPI schema is the only feature why I would want to use TypedResult, but it's quite common for a single endpoint to return many return types and also do some deep schema adjustments, so manual interventions are almost always needed, therefore a single additional line addOpenApiSimple for simple cases doesn't look too bad to me.

endpoints start feeling a lot more like pure functions: take in an input and return an output

You can still use typed results everywhere in your code and use either ctx.Write or % operator and pass IResult at the very end.

More specifically that Task<IResult> is a potentially more useful return type for an endpoint than unit Task.

TBH, Task<IResult> doesn't make much sense to me, since IResult is already and object with interface HttpContext -> Task, so it actually becomes Task<HttpContext -> Task>, which is quite difficult to comprehend

[WorldMaker]

Yeah, maybe IResult isn't the best option. I think the key thing I'm wondering if there's a better way to reduce the "imperative shell" out of framework user code and yeah, this:

At the same time, being functional has never been Oxpecker's goal.

Got it. Not a problem. If it's explicitly not a goal I won't pursue. That's why I asked.