Re: HTTP2: Are we there yet?

[James Tucker <jftucker@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6429 bytes --]

On Fri, Jan 15, 2016 at 2:28 PM, Tiago Cardoso <honeyryderchuck@gmail.com>
wrote:

> Hi, I've been looking for developments in the rack framework concerning
> its update towards great big http2. I've seen the presentation from Aaron
> Patterson from October/November, and since then, only seen the events
> middleware landing in master. And there's an alpha 2.0 version.
>
> I assume that http2 won't come with 2.0 . Still, I'd like to know where we
> stand, what's missing for rack to develop further in that direction and
> where could I help/contribute. Hopefully there's a document someone can
> redirect me to.
>

First of all, the Rack SPEC is not incompatible with http2 today. You can
use Rack in an http2 server.

What does not exist is new mappings for a server push API. Note that
promises (server push) is only additional responses shipped alongside a
response. It is not a general IO mechanism.

Rack is primarily a framework/interface layer between Ruby webservers and
Ruby web applications, as implemented today. That means it's really focused
on the HTTP parts, and while http2 can carry other protocols, I would
expect that Rack should probably remain an interface layer for http1 over
http2, not * over http2. It's conceivable that something could move into
such a space, and maybe that could be called Rack, but it would be an
entirely different specification, with entirely different goals and
complexities.

The synchronous single-call design of the Rack SPEC will always be a
problem for fuller http2 services (e.g. grpc) as they are not request
response protocols and don't fit into that model. In the same way, as that
doesn't fit, none of the middleware fits either. I wrote about this years
ago.

I'm really looking forward to hearing from someone, possibly Mr. Patterson,
> who's clearly been working in this. I think ruby needs http2 badly. I think
> that all other standards for pushing
> server-to-client/full-duplex/pipe-in-my-json will die after widespread
> adoption, like image spriting and all those HTTP1 performance
> "enhancements".
>

http2 does not offer full-duplex for web applications today. No browser
exposes server push to javascript or anything like that, and even
websockets over http2 is as yet undefined - there's only a spec that's
been dead
for over a year and a half
<https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01>.
You can use SSE over http2 today, and if you were using an HTTP2 enabled
Rack compatible server, SSE like this would work
<https://gist.github.com/raggi/ff7971991297e5c8a1ce>. In fact, not only
"would work", but does work. I use nginx to terminate http2 today, and have
http1 rack backends running SSE like this in the wild, and it works just
fine.


> I think that the ruby frameworks don't need and should not enforce
> websockets, specially for thing it was not designed for. I think
> ActionCable is crap. And just as Rails, I am entitled to an opinion, and
> would like to try to force it into people's throats. And I'd like to force
> http2 and consider myself a better human being after that.
>

I've been down this battle with realtime ruby for years, and so did the
author of node before he went and wrote node. That's part of where that
came form. The fact that ActionCable relies on EventMachine makes me really
quite sad as we've largely stopped maintaining that for important reasons
for a long time. The real issue here is that we've never had any good SPEC
proposals for specs that handle realtime well, and we have tons of
streaming bugs in the core middleware. We fixed a lot of them over the last
two years, but I'm sure there are more. Things like the Content-Length and
Chunking middleware should *never* have existed, and the fact that they do
is an ongoing problem for server authors venturing into this domain.

Realtime sockets are also very hard to load balance and scale, and while
that might not be actioncables concern, it's a concern for real users in
the wild. What most people do today who do this stuff is use external
services, rather than putting such things in their monoliths. Users already
have very real load balancing problems with high standard deviation
response rates
<http://genius.com/James-somers-herokus-ugly-secret-annotated> and sadly as
in the linked example, they often fail to understand the issues here. While
some work has gone into better open source load balancers
<https://www.nginx.com/blog/choosing-nginx-plus-load-balancing-techniques/>,
we still have a long way to go to match up with commercial offerings, and
in fact the linked stuff is at least partially commercial only. If you're
not using a third party service for realtime persistent sockets, then
you'll probably want to use a separate service, because of the many
challenges inherent with otherwise muxing it in through your primary
serving routes, and indeed that's what we all do.

Only thing I found was this:
> https://groups.google.com/forum/#!topic/rack-devel/lipvWVZrcfo and after
> the author left the project. What's the status?
>

It's not going anywhere because no one is stepping up to do it. Please
understand that stepping up to do it means actually getting something
working that works for a wide array of use cases, not just putting your
hand in the air and saying "I'll do it" - just that we've seen that many
times, even I did that once and I knew better than to volunteer so much of
my free time.

I don't mean to discourage you though, I would really love to see this
happen and if you have the time to start writing test cases and developing
a real API for this, I'd be more than happy to provide guidance and
feedback. That goes for everyone else too, and it's not the first time I've
said it. As with the above, no ones yet taken up the offer.

Really appreciate any feedback,
> Tiago
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Rack Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rack-devel+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 8385 bytes --]