Communication with backend servers should be message-oriented.I don’t see anything in Rack that stops us from doing this at the moment. Connections to backend servers should be persistent.While it isn’t the default, Rack at least supports streaming responses (it has for a while, at least). Request and Response streaming should be the default.Unfortunately, Rack is incompatible with most of these principles: Ilya Grigorik, Google’s public web performance advocate, has laid out 4 principles for the web architecture of the future. In a lot of ways, HTTP/2’s architecture will probably mean that whatever solution we come up with will bear more resemblance to ActionCable than it does to to Rack 1.0. Part of the reason why progress has been slow here (other than, apparently, that is the only one that wants to work on this stuff) is that Rack is thoroughly designed for an HTTP/1.1 world.
Until the situation changes at the Rack level, Rails and all other Ruby web frameworks are stuck with HTTP/1.1. While it was discussed that this would change with Rack 2 and Rails 5, very little actually changed. While has done some experiments with HTTP/2, Rack remains firmly stuck in an HTTP/1.1 world.
Ilya Grigorik has written an experimental HTTP/2 webserver in Ruby, but it’s not compatible with Rack, and therefore not compatible with any Ruby web framework. Uh, hello Aaron? Yeah, could you like, fix Rack please? So, I can use HTTP/2 in my Ruby application today, right? After all, Google says that some pages can load up to 50% faster just by adding HTTP/2/SPDY support, it’s magical web-speed pixie dust! Let’s get it going! As of writing (December 2015), estimates about 70% of browsers globally can now support HTTP/2.
HTTP/2 is coming! No, wait, HTTP/2 is here! After publication in Q1 of 2015, HTTP/2 is now an “official thing” in Web-land. Summary: Full HTTP/2 support for Ruby web frameworks is a long way off - but that doesn't mean you can't benefit from HTTP/2 today! (2112 words/11 minutes)
0 kommentar(er)
