* ewer -  flask inspired microframework

** 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.