** remarks
aim is to provide the original author (me) essential capabilities for modern cloud native services writing in a portable and simple way.
things like tls are handled by the load balancers.
most web frameworks seek to simplify by having a single point of contact.
this isn't useful when integrating multiple libraries. Java Spring is not a good software design.
** what is to be done
routing
hooks for cross-cutting concerns as they relate to middleware
nice to haves
parameterized url parsing
mounting of routes
built on tiny_http
it's synchronous. largely because my analysis of async is that it's a theoretical kludge at both the typing and threading level(see remarks).
I'm building this library for myself, for my needs.
this isn't built for ultra-high traffic; most shops don't have ultra high traffic. my current web service of interest has < 1qps. what I need is a framework that gets out of my way in a hurry.
supposing you want to adopt this, characterize your load and architecure as part of a pilot project, verifying it meets your edge cases.
happy hacking ~pnathan
** remarks
async, roughly, lifts relevant functions into an Async monad, and each
request executes within Async a and thus interop with normal code is
generally a total mess.
while epoll(7) is a fine piece of design, building web frameworks in a way that uses monadic design without frontally treating the monadic type generates some genuinely convoluted code.
my personal experience here is in JavaScript (Typescript), OCaml, some Python, and a smattering of Rust.
I would suggest that quite likely, the solution here shouldn't be async, but a more sophisticated thread pool/channel model with appropriate semaphores.