5 ms·
Just to throw my hat in the ring, Currently CTO /founding engineer of health tech company that runs a Rails backend that serves about 150QPS. I hear over and o
by czhu12 5y ago
Just to throw my hat in the ring, Currently CTO /founding engineer of health tech company that runs a Rails backend that serves about 150QPS.
I hear over and over that rails doesn’t “scale”.
Performance wise, we have never had a problem scaling rails itself. The issues were always at the database level. Most slow endpoints (1.5s+) are 10% Ruby, 90% Postgres.
Even if Ruby was magically infinitely fast, these endpoints would go from 1.5s -> 1.35s.
Optimizing data infrastructure gets 10x returns compared to the application code.
Maintenance wise, it’s a bit harder, Rails loves to put everything in the global namespace. This comes down to your team being conscious of properly namespacing different logical parts of your app.
- jasonhansel 5y agoAgreed. Scaling application servers is "easy" since they can be scaled horizontally; in other words, you can just throw more hardware at the problem. Scaling databases is "hard" because of CAP/PACELC-type issues in maintaining consistency, and because some DBs (like Postgres) don't have good support for horizontal scaling.
- stepbeek 5y agoI’ve found DDD’s insistence that cross-aggregate aggregation be done through IDs to be helpful here. It makes transitioning to other persistence implementations easier.
- ylhert 5y agoPreach! I do not understand this criticism at all. Rails scales just fine, in a web app it's the DB that's the bottleneck 99% of the time. Sure, the ORM can get you into hot water easily if you do dumb things (or just don't pay enough attention to N+1's etc), but one should be using the ORM wisely and deliberately, rather than living ignorantly of what's happening behind the scenes.
- lab14 5y agoHaving built a Rails app with my team that handles ~76k rpm on peak days (99% of responses within 90ms), I've learned that you scale your architecture, not your framework. Rails is just fine.
- cdiamand 5y agoAnyone have any recommendations for books or resources to look at when scaling a rails app beyond a single database, or when your app starts to move into the realm of "big data"? Asking for.... a friend.
- montblanc 5y agoRails 6 has support for multiple dbs ...
- ROFISH 5y agoYou can "componentize" various parts of Rails and make it less of a monolith by using Rails engines. I do it by having a new folder "components" on the Rails root and adding `gem 'name_of_component', path: 'components/name_of_component'` which looks like a vendored gem. Rails engines has the ability to "isolate_namespace" which is I think the default for a new engine. This is where you can avoid global name spacing issues where each component can be thought of separately. Effectively, you have something _kinda_ like a microservice but it runs as a monolith. And if you need you can have each component depend on others so long as you don't wind up in a loop. Note: I have a component "common_models" which is just for commonly used items across various components. The main app should have nothing in it's Rails.root/app since you instead have components. I'm not related to this but here's a basic idea: https://cbra.info https://cbra.info . (Pretty sure the author of this page made the Railsconf talk that inspired me to move to this years ago.)