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

[PJ Eby]

On Tue, Sep 30, 2014 at 4:09 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
> 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.

I'm not sure I see that, but perhaps I'm missing something.  The
assumption I'm making is that for most applications, most of their
code is going to be tightly coupled to whatever web framework they are
using.  Even the part of their app that uses websockets or HTTP/2
features, is *mostly* going to be dealing with application concerns,
not websocket or HTTP/2 concerns.  There should only be a very small
amount of application surface that is either calling or called by the
native API.

IOW, I don't see how the native API-coupled part of an application is
ever going to be a significant body of code, compared to the part that
would be the same if ported to a different API.  Most of the
API-coupled bits are going to just be ways to say "send this" or "call
me when you receive this", or the like.

But again, maybe I am missing something?

(In any case, the existence of an escape protocol also allows
independent development of standardized native APIs, e.g. one for
websockets and another for HTTP/2, without requiring them to all be
developed at once.)


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

Currently, some web servers already *have* websocket and HTTP/2 APIs.
But you have to "go native" to use them right now, and you can't take
advantage of your framework parts if you have a request that's
entirely handled by a native API.  The idea here is to bridge *that*
gap.


> 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?

He doesn't have to.  The point of the suggested
`response.use_native_api()` is that it's *generic*:  the *user*
invokes `use_native_api('uWSGI', my_uwsgi_handler)` or
`use_native_api('gunicorn', my_gunicorn_handler)`.

In other words, the frramework doesn't care *what* API the app is
escaping to.  And, as long as the framework has a way to specify its
outgoing status, headers, and body, it isn't even necessary for the
framework to provide the `use_native_api()` escape -- it's just a
little more work for the user.

The main idea here is that the user can still use the framework up
until the point where it has loaded all their session, user, etc.
data, routed, preconditioned, and everything else...  and then the
user can pop back out to a low-level API to do things the framework
can't yet do.


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

My suggestion would be for severs that already have a non-WSGI API to
implement a mensa escape for it, so that people can begin using it at
once.  I would also suggest that framework authors provide a way to
invoke a mensa escape from their framework, in order to be able to use
those existing APIs today.  (And since many frameworks either use
WebOb internally or expose the WebOb response to their users, a WebOb
implementation of a use_native_api() response would immediately enable
a lot of experimentation.)

I do not suggest that anybody make up *new* native APIs, until we have
a chance to see what can be done with existing ones when you have the
ability to integrate those APIs with existing WSGI-based apps and
frameworks.  But that doesn't mean it can't happen.


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

That can certainly be done, but I don't personally have the expertise
to work on those other APIs directly at the moment.  But since I *do*
have some expertise in WSGI and its various quirks and corners, I
*can* provide assistance with the escape mechanism.  ;-)

I guess maybe the bit about "tabling" this part was a little too
tongue-in-cheek with the "mensa" pun.  I do not actually mean that
nobody should do any common API development.  I only mean that, it
should not be necessary for anyone right now to *wait* on a standard
before being able to use the APIs that already exist today.

As soon as anybody with a server exposes a native API hook, it becomes
*possible* to do the sort of versioning and collaborating you're
talking about, *without* having to include the escape mechanism or
other WSGI plumbing details into the design of something that really
isn't WSGI-as-we-know-it.  I just want the mensa protocol to be the
booster rocket to your satellite: something that gets you off the
ground, while you guys worry about what to do once you reach orbit.
;-)