You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a fan of the original railway style routers, but I understand that they're limited by the fact that they can't be analyzed before they're executed, which makes it difficult to do things like implement OpenAPI support.
Meanwhile, endpoint routing has some downsides beyond just the documented lack of case sensitivity:
Trailing slashes are ignored, which means foo and foo/ land on the same route -- which is problematic when trying to use relative paths in the browser
The verb always has to come first, which isn't ideal for organizing REST style APIs, e.g. GET [ route "/cats" ]; POST [ route "/cats" ]; DELETE [ route "/cats" ]
The WithExtensions functions are useful but requires rather verbose invocations of ASP.NET API
I miss subRoutef
With quotations, OpenAPI information could be annotated per-route in as composable a manner as the rest of the router itself.
I think it would be interesting to have a router that leverages code quotations to make this possible using railway style, as well as to do some crazy optimizations, for example:
Expand out every possible route and combine all consecutive route and routef calls into simple string comparisons
Replace all other >=> s with if-else ladders or pattern matching
Use access statistics to reorder the route evaluation so that the most common routes are tested first
Likewise reorganize VERB >=> route or route >=> VERB if-else ladders to optimize
Likewise bump requiresAuthentication to the top of the if-else ladder if there are a lot of auth failures, i.e. if being DOSed or probed
More generally, use System.Diagnostics.Stopwatch to gather performance stats on each handler and reorganize them accordingly
Getting the semantics right might take some work, but I kind of wonder if it might earn the crown for fastest router in ASP.NET.
In terms of usage, it probably wouldn't look much different from the original railway routers, except that it would be an Expr<HttpHandler> as opposed to an HttpHandler:
letapp=<@ choose [
route "/foo">=> choose [
GET >=> fooHandler
POST >=> postFooHandler
]
GET >=> route "/bar">=>[
route "/fizz">=> fizzHandler
route "/buzz">=> requiresAuthentication >=> addOpenApiSimple<int, Product>>=> buzzHandler
]]@>
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Yet another router idea...
I'm a fan of the original railway style routers, but I understand that they're limited by the fact that they can't be analyzed before they're executed, which makes it difficult to do things like implement OpenAPI support.
Meanwhile, endpoint routing has some downsides beyond just the documented lack of case sensitivity:
fooandfoo/land on the same route -- which is problematic when trying to use relative paths in the browserGET [ route "/cats" ]; POST [ route "/cats" ]; DELETE [ route "/cats" ]subRoutefWith quotations, OpenAPI information could be annotated per-route in as composable a manner as the rest of the router itself.
I think it would be interesting to have a router that leverages code quotations to make this possible using railway style, as well as to do some crazy optimizations, for example:
routeandroutefcalls into simple string comparisons>=>s with if-else ladders or pattern matchingVERB >=> routeorroute >=> VERBif-else ladders to optimizerequiresAuthenticationto the top of the if-else ladder if there are a lot of auth failures, i.e. if being DOSed or probedSystem.Diagnostics.Stopwatchto gather performance stats on each handler and reorganize them accordinglyGetting the semantics right might take some work, but I kind of wonder if it might earn the crown for fastest router in ASP.NET.
In terms of usage, it probably wouldn't look much different from the original railway routers, except that it would be an
Expr<HttpHandler>as opposed to anHttpHandler:Could be compiled to something like:
Beta Was this translation helpful? Give feedback.
All reactions