Explaining Thruster, a new 37signals gem that speeds up your app

My original post says I do not recommend traditional CDNs because I assumed those had extra setup configuration (which I have already been correct on by another dev, but unfortunately I can no longer edit the original post) and because cloudfront and others, AFAIK, charge you for egress.

Honest question: Compared to Cloudflare, which is free, which non-proxy CDN would you recommend and why? I know there are use cases that might require them, but for the target audience I had in mind (people who don’t have much experience in devops and need to learn a bit because they now have the handle their startup devops) I don’t think those would be a better option than cloudflare.

It looks like Heroku will be supporting HTTP/2 soon

How does that affect

Thruster only: You cannot use a reverse proxy CDN and are using a PaaS like Heroku. Just be aware that Heroku’s router only supports HTTP/1.1, when communicating with clients, so even if you add Thruster you won’t get HTTP/2

Correct me if I’m wrong but it seems that Rack iterates through the file (in Ruby) when serving them anyway, so it would be notably more blocking than Thruster anyway.

If you’re using Rack::Files to serve your static assets, then that might be true. That isn’t typical for a Rails application though. If your response body is an open file, Puma (and probably Unicorn as well as other servers) will use IO.copy_stream which does not block.

It seems to be used by Rails as well

Great find! Though that just seems to be an allocation, not a usage. Seems its only conditionally used. It would be great if someone were to figure out why we need it, and whether or not it is possible to have that middleware return a file handle. I don’t have time to investigate this though, so I’d appreciate if someone else could.