This was a very Ruby-centric take (not surprising, the author is on the Rails core team). It’s true that if you’re not a CDN then HTTP/2 probably has little impact on you as a developer…unless you use bi-directional streaming.
HTTP/2 adds bi-directional streaming, which moves HTTP from a serial request-response model to a concurrent request-response model. This unlocks way richer API design in browser-less environments like backend services. It’s probably most often utilized in gRPC services that use client and/or server streaming.
As a longtime-sometimes Rubyist, I get why there’s not a lot of love for bi-directional streaming. But it’s disappointing because it means that there are better languages & frameworks out there for certain types of backend APIs.
Yes, everything published on my blog should be read from a Ruby point of view and I believe the intro does a good enough job at explaining the scope of my opinion:
From time to time, either online or at conferences, I hear people complain about the lack of support for HTTP/2 in Ruby HTTP servers, generally Puma.
And yes, gRPC is probably the only reason you’d want full HTTP/2 support in a Ruby server, but the official grpc bindings for Ruby are so terrible that I wouldn’t recommend to try to do gRPC with Ruby to my worst enemy, and much simpler protocols like Twirp would give you 90% of the capabilities with much less headaches.
I would agree with this take for HTTP/3, but not for HTTP/2. There are many reasons to prefer HTTP/2 over HTTP/1.1 in a service oriented architecture.
Multiplexing is a big one. Aside from improving HOL blocking for web clients, it also simplifies connection pool management. Instead of needing to assign a connection per concurrent request, you can instead send all of your requests over a single connection. You will eventually run into TCP HOL blocking constraints (hence HTTP/3) but it’s still a significant improvement over the complexity of managing a connection pool.
HPACK can be very useful, especially if you send large repetitive headers. And I’m not going to say no to first class interrupts (client RST_STREAM), Nacks (server RST_STREAM), or graceful draining (GOAWAY). These are all problems which can only be solved very awkwardly if all you have is TCP and HTTP/1.1.
The flow control APIs are also a big win, but not every architecture needs streaming between services, so it’s not as important for me as these other features.
This was a very Ruby-centric take (not surprising, the author is on the Rails core team). It’s true that if you’re not a CDN then HTTP/2 probably has little impact on you as a developer…unless you use bi-directional streaming.
HTTP/2 adds bi-directional streaming, which moves HTTP from a serial request-response model to a concurrent request-response model. This unlocks way richer API design in browser-less environments like backend services. It’s probably most often utilized in gRPC services that use client and/or server streaming.
As a longtime-sometimes Rubyist, I get why there’s not a lot of love for bi-directional streaming. But it’s disappointing because it means that there are better languages & frameworks out there for certain types of backend APIs.
Yes, everything published on my blog should be read from a Ruby point of view and I believe the intro does a good enough job at explaining the scope of my opinion:
And yes, gRPC is probably the only reason you’d want full HTTP/2 support in a Ruby server, but the official
grpcbindings for Ruby are so terrible that I wouldn’t recommend to try to do gRPC with Ruby to my worst enemy, and much simpler protocols like Twirp would give you 90% of the capabilities with much less headaches.So it’s not really among my concerns.
I would agree with this take for HTTP/3, but not for HTTP/2. There are many reasons to prefer HTTP/2 over HTTP/1.1 in a service oriented architecture.
Multiplexing is a big one. Aside from improving HOL blocking for web clients, it also simplifies connection pool management. Instead of needing to assign a connection per concurrent request, you can instead send all of your requests over a single connection. You will eventually run into TCP HOL blocking constraints (hence HTTP/3) but it’s still a significant improvement over the complexity of managing a connection pool.
HPACK can be very useful, especially if you send large repetitive headers. And I’m not going to say no to first class interrupts (client RST_STREAM), Nacks (server RST_STREAM), or graceful draining (GOAWAY). These are all problems which can only be solved very awkwardly if all you have is TCP and HTTP/1.1.
The flow control APIs are also a big win, but not every architecture needs streaming between services, so it’s not as important for me as these other features.