Coming from Zeit Now/Next.js where I remember HTTP/2 was described as important for performance, for me as a complete non-expert it felt as a regression when I came to Rails/Heroku with the recommended Puma HTTP1.1 server; also ActionCable uses Websockets which has its limitations and is said not to be so needed with HTTP/2 (thanks to this thread for the link).
As an experiment I tried adding early hints to Puma but encountered blank page issues (reported by users, which I could then reproduce via an ngrok to my dev server).
A version number in itself does not mean anything, so do we need to care at all? What are the current framework limitations and opportunities in relation to H2? I would be grateful for any info on historical choices and the planned direction for HTTP/2 in relation to Rails.
Rails needs to be extremely careful here. HTTP/2 push is not a silver bullet. In some cases it can save an RTT for your various assets, in other cases you can end up pushing a whole bunch of data to the client in the wrong order and not gain anything out of it.
At the core HTTP/2 push is an optimization you would apply very carefully to site based on benchmarking access from a bunch of places in the world.
If you have enough CDN points close to the clients the RTT can become negligible. I am in Sydney. I reload this page … the page comes from San Jose, but the assets all come from Sydney that is really close to me. Cutting 20ms RTT down to my CDN would not gain me much.
HTTP/2 on the other hand is something almost all large scale Rails project use. We never put Puma in the wild on the Internet, there is always a proxy in front be it NGINX, NGINX+Varnish/HAProxy, Apache or the experimental H2O.
I really think the only big action item would be ensuring documentation covers how you go about hosting Rails in the wild.
Many other optimisations come much cheaper HTTP/2 server push. CDNs, Latest SSL protocols, plain old HTTP/2 and so on.
Also keep in mind Rails is not going to be doing the pushing, this is a dance between Rails and whatever proxy server that is fronting it.
What samsaffron said. We’re running HTTP/2 with HEY through nginx. The main benefit is higher concurrent loads and just a single HTTPS handshake. I don’t think HTTP/2 push is actually that interesting for most web apps, and I don’t think they’re a replacement for web sockets either.
NB: it is samsaffron who wrote that HTTP/2 could be seen as an alternative to WebSockets:
In a world that already had HTTP/2 it is very unlikely we would see WebSockets being ratified as it covers that vast majority of use cases WebSockets solves.
I agree 100% that HTTP/2 push is not a replacement for web sockets or event source. They are totally different beasts that exist for totally different use cases.
HTTP/2 with EventSource or XMLHttpRequest with chunked encoding do very efficient half duplex communications from a server to a client. Since HTTP/2 multiplexes, you effectively get full duplex by doing standard REST for upstream and chunked encoding for downstream.
As far as I know HTTP/2 or 3 still have not figured out how to give Web Sockets a shared home on the multiplexed connection used. I have not checked in the last 6 or so months, it may have changed.
As someone who found your original “caution” post really insightful, I’d really thrilled if you ever followed it up with a contemporary “it’s been five years, here’s what got better, here’s what’s still worrisome, here’s what I was probably right to be concerned about but it turned out to not be so bad after all” post.
For better or worse, you’ve got the market on caution for websockets locked up.
Although I think Rails 7 taking further steps towards the direction of HTTP2 is a good thing (especially with introduction of Importmap) I want to point out most popular hosting for RoR newcomers Heroku does not support http2 Which is a shame but on other hand if there is a Cloudflare DNS in front of the heroku app it seems the communication between browser and cloudflare is HTTP2 (or even HTTP3) .
Similar way some cloud solutions that may support HTTP2 between Browser and Load Balancer may then resolve the communication between LoadBalancer to instances with HTTP1.1.
How much issue this is ? for my implementations of Rails there are no issues, but maybe someone can think of a scenario where this is an issue for their project.
However from what I’ve seen one of our websites https://www.pobble365.com/ hosted on Heroku and Cloudflare is enabled as DNS. When I inspect it it seems the connection is “H3” …that is HTTP3 no ?
