Highlighting Hypercorn.

[tomchristie]

So,

I think we'd do well to highlight alternate ASGI servers way more prominently. Likely on the README/homepage.

Hypercorn is particularly worthy of note here simply because of the way the landscape has evolved...

• Uvicorn has to "compete" against lightweight async Python options, and help demonstrate that good server/client separation isn't a "performance" concern. It happens to be implemented directly on asyncio, which is ffffiiiinnnnneeee, although...
• Hypercorn came along a little later, and was able to instead fill the gap of being implemented on top of structured concurrency principles. (Either Trio, or AnyIO for asyncio support.) As a result there's may well? be a slice of places where it's actually more resilient. Certainly if I had a straight up choice between two otherwise-equivalent options and one was engineered primarily from that perspective, and the other not, then I would almost certainly choose the structured concurrency one, rather than paying too much attention to nebulous benchmarking.

We could also consider highlighting Daphne, too. Pretty sure that'll have had a good chunk of traffic flowing through it, it's been around longer than Uvicorn, has had stacks of usage in the Django community, and is likely a very resilient option as a result.

There's also a decent case to make that having diversity of design aims amongst the server ecosystem would serve the community better, than having us aim at the same targets. There's an argument here to be made that #1026 is perhaps not something we ought to aim for. Arguably we might prefer that...

• Uvicorn: A fast HTTP/1.1 + websockets server, on top of asyncio directly.
• Hypercorn: An HTTP/1.1, HTTP/2, (HTTP/3?) + websockets server, on top of structured concurrency principles.
• Daphne: A well trodden, HTTP/1.1, HTTP/2 + websockets server, on top of the reliably mature twisted stack.

(There's a similar conversation I've seen voiced around a whole bunch of dynamic programming languages all just evolving to be variants of the same monoculture approach, and the trade-offs between that generalist approach, vs. having some very particularly targeted languages spaces that eschew the centre-point. Eg. the very specific design constraints that Go chooses to sit within.)

In any case I think a vibrant server ecosystem would serve us all well here. Uvicorn is perhaps a bit dominant, so using that platform to highlight alternatives would be a great idea.

/cc @andrewgodwin, @pgjones perhaps?

[synodriver]

Emmm... is that means http2 support is put off? Accroding to this benchmark, uvicorn achieved roughly 40% more throughput than the others in this test. If uvicorn could support other protocols(like http2) at the same time, it will hava a more vibrant server ecosystem.As for "structured concurrency principles", users may not care about this.maybe?

[tomchristie]

I'll re-phrase the case here... adding HTTP/2 support to Uvicorn will come with a huge cost.

The added complexity and ongoing maintainence burden it adds is very significant.
If we're more narrowly scoped then the slice of functionality that we do choose to offer will be better off as a result of being able to stay more tightly targeted.

(It's also that case that in many deployment environments uvicorn will anyways be running behind fronting servers that can relay in HTTP/1.1 or HTTP/2.)

[synodriver]

Well... I've know why HTTP/2 is dropped. It would be better with HTTP/2 support, but if it cost too much, just drop it then. Although I prefer that one with h2 support(personally) and feel disappointed to lose it. Still, I like the the multiprocess and reload part of uvicorn so I made a fork of uvicorn, hoping to be a general tcp/udp server with all protocol supported

[devxpy]

Worth noting that if you use uvicron behind nginx, you get edge support for http/2 (see here)

[Kludex]

This implies closing the door for structured concurrency (trio) on uvicorn? As discussed on the long #169

[tomchristie]

So, I've crossed one of my own lines that I ask other folks not to do, and have started conflating some different issues into this one. "Highlighting Hypercorn" should stand alone as an actionable item, either way.

The somewhat related issues of:

• Should we support HTTP/2, or draw a tighter scope.
• Should we add Trio support.

Are both separate. I'm very much in favour of Trio. I don't know if Uvicorn adding Trio support makes sense or not, because it'd need a chunk of redesign, and I'm not able to take a call on any tradeoffs it'd introduce. In particular it's fairly likely that in engineering things so that we can add Trio neatly, we'd end up with the asyncio version appearing slower in benchmarking fluff, which might or might not be a trade-off we'd be willing to make, hard to say. But anyways, we should, just consider #169 on it's own merits.

The more general point is simply that I'd like us to promote the other server options, and also that we don't necessarily have to go toe-to-toe with them on features.

[andrewgodwin]

I'm all for highlighting alternatives - not sure I'd care too much about Daphne, though it does seem to have been pretty reliable over the years, likely thanks to a lot of the Twisted folks' work.

[pgjones]

I think the community doesn't have much desire for Python HTTP/2 or HTTP/3 servers, but does have a very strong desire for fast HTTP/1 servers. I put this down to production usages having something that terminates the HTTP/2 (or 3) between the Python server and the browser and that neither HTTP/2 or 3 provide a strong gain within a data center. (I am committed to support both in Hypercorn though, with HTTP/3 waiting on openSSL support). I this regard I think if uvicorn focuses on being the fastest HTTP/1 ASGI server then the community will be well served.

As for structured concurrency, I think we will be waiting a number of years before we can use it in asyncio unless we stop supporting Python versions. I don't think the community would approve if we did drop versions early - a very large fraction Hypercorn users are using a version that supports Python 3.6 which I stopped supporting a couple of years ago. Edit: This assumes the except* (or other multi error solution) makes it into Python and that TaskGroups (or other) follows after.

[tomchristie]

Thanks Phil.

I think your first point is spot-on.

Wrt. the second point, I'm very much sold on working within structured concurrency constraints at this point. AnyIO is the missing package for asyncio, and gets us all the way there without having to wait for stdlib, whereas there's a strong possibility that Trio is where we'll mostly land up long-term. Having said that I do think it's okay for something like Uvicorn to just be raw asyncio. Stuff like getting backpressure done correctly is more complex, but it is handling all that, so.

Anyways, I'm up for anyone taking on a docs PR to deal with this. Might even get around to it myself if no-one jumps on first.