Hacker News Reader

Comment by agtorre | Hacker News Reader

This is really cool. Is the Rails server production ready? I was always under the impression you had to run it with Uvicorn or similar, although I haven't been following Rails development recently.

View on HN

The default Gemfile now bundles Puma in, so yeah it's production ready

Puma is certainly fine as the app server - but normally you'd still have a proxy/load balancer/tls terminator/"ingress server" in front. Something like traefik, nginx, haproxy or caddy.

If (one of the) front-facing servers do regular http caching (a good idea anyway to play nice with rails caching[1])", you can probably "serve" the static assets straight from rails and let your proxy serve them from cache (if you don't have/need a full cdn).

[1] https://guides.rubyonrails.org/caching_with_rails.html#condi...

Yes, usually you still serve your asset (images,...) directory through nginx or something similar, though.

This has been my experience too, and I've never even used Rails at scale. Puma will struggle to serve "lots" (tens on a single page) of (for example) static images (though the actual user experience varies across browsers - safari does okay but firefox chokes and chromium is in the middle). This is with puma on a decent intel prosumer CPU (an i7 iirc) using x-sendfiles through nginx. So puma isn't even actually pushing the image bytes here.

I replaced it with nginx intercepting the image URLs to serve them without even letting puma know and it was instantly zippy. I still use sendfile to support when I'm doing dev and not running nginx in front of it, and I'm not happy with the kind of leaky abstraction there, but damn are the benefits in prod too difficult to ignore.

Serving the assets directly with the Rails app, but with a CDN caching layer in front, is also common, and is what heroku for instance recommends.

Reply on news.ycombinator.com