I've heard from lots of folks in the Rails community that getting http/2 and streaming into Rails has been a slow and tedious process. I'm not saying it's going to be "a good fit for everything"—what I am saying is that it will be nice when we can run IO bound workloads in Rails without feeling like a fish out of water.

"it's certainly not a good fit for the overwhelming majority of Rails applications".

In my experience, most web applications are terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound, so I'm not sure how this wouldn't be a good fit for most Rails applications.

> getting http/2 and streaming into Rails has been a slow and tedious process

Bringing http/2 all the way to the Rails process doesn't bring anything to the table. You're much better to terminate http2 or 3 with SSL at the LB.

> terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound

It absolutely isn't unless your data access is really messed up (badly indexed queries or tons of N+1).

Even if you are just serializing the data you got from the DB down into JSON with little to no transformation, you'll likely end up spending more than 50% doing CPU work.

Look at all the reports of YJIT speeding up Rails applications by 15 to 30%. If Rails apps were truly IO bound like people claim, YJIT would have nothing to speedup.

Even if your app is 90% IO, you can slap Puma with 10 thread and will already suffer from contention. Async make sense when you'd need more than a dozen threads or so does. Before that it doesn't make a substantial difference. Like it would be great to use for Action Cable, but that's it.

> In my experience, most web applications are terminating HTTP connections from clients, then reaching out over a network to database servers, etc. to do work. This is very much IO-bound, so I'm not sure how this wouldn't be a good fit for most Rails applications.

Most rails applications are deployed using a multi-threaded application server such as Puma, a thread processes a single request and when it encounters IO (or calls out to a C function) the thread gives up its hold of the GVL and another thread can run. You can use 100% of your resources this way without the added complexity of parallelism within a single request.

Are there truly people out there that are terminating HTTP/2 at the application level? That's really quite surprising for anything serving production traffic.