[Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

[Cory Benfield]

On 30 September 2014 08:41, Roberto De Ioris <roberto at unbit.it> wrote:
> While i totally like your proposal, i fear it will not solve one of the
> biggest problems without another layer:
>
> currently (and i speak as the uWSGI author, so i am the first guilty here)
> when you want to use non-WSGI features you generally call into server api
> (like the one exposed in the 'uwsgi' virtual module). This means each
> server has its api, and this result as middlewares and apps to be adapted
> to each one (if possible)
>
> My proposal is to push "mensa" but to standardize a series of api
> (websockets and push at least) on top of it so that frameworks and
> middlewares can use them without worrying about the lower stack.

This was exactly the concern I was about to articulate. Having a
standard way to 'escape' WSGI is great, but what it does is force us
down a road where any application that wants to use HTTP/2 or
WebSockets picks one server at the start of its life and is
effectively tied to that server.

Any application small enough to be easily ported is also small enough
that it isn't a reasonable test of the API. Any application large
enough to really provide insight into the APIs is also large enough
that it will rapidly become tightly coupled to its server
implementation.

Additionally, it's a cost for server authors (unless they think they
really do have the ability to provide the 'best' API around which all
of us will rally). Server authors are going to have enough work just
making their servers speak HTTP/2 out the front, asking them to also
invest work in designing an API that *might* get used by a small
fraction of applications is really a big ask.

Finally, the odds of us getting buy-in from frameworks is surely not
very high. What interest will, for example, Armin Ronacher have in
having support for uWSGI's specific HTTP/2 API in werkzeug/Flask? What
about gunicorn's? Or mod_wsgi's?

I appreciate the argument for wanting to let server+middleware authors
develop the APIs themselves and then standardise around it, I really
do. But without a concrete plan of who is going to make the first
investment, I think it just leaves us sitting around doing nothing. A
better approach would be to say, as Roberto suggested, "hey, here's
this generic WSGI escape mechanism, and here are some generic HTTP/2
and Websocket APIs you can escape to". We could even version those
APIs, allowing for communal development of them between server
authors. That provides the initial escape hook and an initial
direction, reducing the risk for individual server authors.