Re:Reading the Ruby Source to Understand Rails Idiosyncrasies
by grey-area on Sunday July 21, 2013 @04:37AM
(#6078252)
It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too).
It's interesting because I've had exactly the opposite experience with Rails in production environments. I prefer to prototype with something simpler, but have found Rails pretty solid for delivering full websites with a complex back-end and tens of thousands of daily users (hardly web-scale, but not insignificant either - probably most sites fall in this bracket). Not that it's the only solution in that space, there are lots of other suitable frameworks, but I'd say it's not bad. It will use more resources than some other solutions, so it's definitely not the most efficient in machine time, but it makes up for that IMHO in being efficient to work with.
We're running some relatively busy sites with Rails and have seen no issues with maintenance or performance (due to caching), and I don't foresee any problems simply because for most web applications you can get acceptable performance up to very high scale by caching selectively. The support for russian-doll style caching and automatic expiration on db changes is pretty good, they're not bad about getting rid of cruft, and over several years I haven't run into any significant maintenance issues. My biggest worry with Rails is security, but that has improved, and is probably better than roll-your-own frameworks anyway.
Having come from Rails 1 and quite a few other web frameworks/CMS solutions, I don't really see Rails as having a lot of magic nowadays, though it does have lots of little shortcuts like scopes, and lots of helpers for everyday tasks like mailing, querying, dates, rendering templates etc. So I've found it a help rather than a hindrance and one of the few frameworks which stays out of your way enough to be worth the trade-off. In particular I like that the conventions mean that when you come back to a project after a few months the decisions on naming and placing functionality will all make sense, if you've followed those conventions.
It would be interesting to know which specific areas you've seen problems on, if only as a warning for others using Rails. I can imagine for example if you didn't want to accept the database naming conventions, or the file naming conventions it'd be a pain to work with and constantly tripping you up.
It's interesting because I've had exactly the opposite experience with Rails in production environments. I prefer to prototype with something simpler, but have found Rails pretty solid for delivering full websites with a complex back-end and tens of thousands of daily users (hardly web-scale, but not insignificant either - probably most sites fall in this bracket). Not that it's the only solution in that space, there are lots of other suitable frameworks, but I'd say it's not bad. It will use more resources than some other solutions, so it's definitely not the most efficient in machine time, but it makes up for that IMHO in being efficient to work with.
We're running some relatively busy sites with Rails and have seen no issues with maintenance or performance (due to caching), and I don't foresee any problems simply because for most web applications you can get acceptable performance up to very high scale by caching selectively. The support for russian-doll style caching and automatic expiration on db changes is pretty good, they're not bad about getting rid of cruft, and over several years I haven't run into any significant maintenance issues. My biggest worry with Rails is security, but that has improved, and is probably better than roll-your-own frameworks anyway.
Having come from Rails 1 and quite a few other web frameworks/CMS solutions, I don't really see Rails as having a lot of magic nowadays, though it does have lots of little shortcuts like scopes, and lots of helpers for everyday tasks like mailing, querying, dates, rendering templates etc. So I've found it a help rather than a hindrance and one of the few frameworks which stays out of your way enough to be worth the trade-off. In particular I like that the conventions mean that when you come back to a project after a few months the decisions on naming and placing functionality will all make sense, if you've followed those conventions.
It would be interesting to know which specific areas you've seen problems on, if only as a warning for others using Rails. I can imagine for example if you didn't want to accept the database naming conventions, or the file naming conventions it'd be a pain to work with and constantly tripping you up.