[iamgilesbowkett]

I have a prejudicial assumption that if you don't know the problem Objectify solves, you haven't worked with a Rails app which has A) a large code base B) a large, active user base and C) a bunch of different features.

The vast majority of people who scale Rails sites (as far as I can tell) do so by breaking their apps into services. ActiveRecord god-objects do not make that step in an app's life cycle easy, and separating persistence from business models is likely to be your first important step when refactoring for scalability. Fragmenting a User model bloated beyond all hope of sanity is almost a rite of passage at this point.

I often think the only Rails developer who hasn't found ActiveRecord bloat to be an irritation and an obstacle to scaling is DHH, and although that makes his opinion on the subject even more valuable than it would normally be, he doesn't talk about it enough in my opinion. Pretty much everyone else, as far as I can tell, responds to Rails scaling issues by creating services in Sinatra and/or divorcing business modeling from persistence logic.

I want someone to challenge my prejudicial assumption here, most of all because I appear to be saying "Rails can't scale," which is BS, but also because I'm very tempted not to take this discussion seriously at all if it doesn't address this point. It's just the crucial point in my opinion. I like the whole OOP thing but to me the decision to use something like Objectify is all about scalability. That doesn't just mean performance; it also means retaining readability when you have a lot of code. Single Responsibility Principle makes code readable.

[stiff]

I worked in Rails for the last 6 years professionally, and for the last 4 years on a single application. There are lots of ways to tackle this problem, but it really depends what precisely you have inside those models and there are certainly no universal silver bullets. Lots of people who complain about this underuse Rails features, external plugins etc. I think two good ways to deal with the problem are:

- Splitting out logical pieces of behaviour into separate modules, especially the ones less central to the core responsibilities of the class. If you look at Rails itself (it's great Ruby code, I highly recommend really reading it), this is the way it is structured, ActiveRecord::Base provides tons of functionality as a single class, yet it still is very neatly laid out into many well-separated modules. See e. g.:

https://gist.github.com/1014971

http://api.rubyonrails.org/classes/ActiveSupport/Concern.htm...

https://github.com/jakehow/concerned_with

http://blog.waxman.me/extending-your-models-in-rails-3

Deciding what things would fit well into external modules and what modules to create is a new skill to be learned, but I think it can work well once you do learn it.

- Things that aren't part of business logic but just handle some more technical matters should be extracted into plugins and not be directly part of the models (for example: special kinds of validations).

- There is the whole world of OO techniques and patterns that can be applied here just like anywhere else. For example you can extract complicated algorithms into separate classes or use value objects:

http://api.rubyonrails.org/classes/ActiveRecord/Aggregations...

[iamgilesbowkett]

hey man, re:

"If you look at Rails itself (it's great Ruby code, I highly recommend really reading it)"

I've worked with a member of Rails core, and frequent committers. I've spoken at 10 Ruby conferences at least, maybe 20. I'm familiar with the Rails code base. I once rewrote a few small pieces of ActiveRecord from memory for a stupid project because my wifi was dead.

I agree about it being worth reading, I just want to slow you down there for a second. Otherwise we're going to end up pulling things out and measuring them. I took the time to check your links, although I'd seen most of them already. I'm familiar with concerns and although I think your links are germane I'd have to disagree with this part:

"Deciding what things would fit well into external modules and what modules to create is a new skill to be learned"

As I think I've learned the skill.

What I'm saying basically is that I think you missed the mark in terms of guessing my background but I believe it was an honest mistake.

Egos aside, I agree that modularity matters. And I must admit I had a painful reminder about that skill recently when I built something around ActiveRecord and then refactored ARec out of the picture for performance reasons (the gains were staggering). It would have been less painful with better modularity, but I don't think the pain relief from using concerns would have been particularly great in this instance. Non-zero, but insignificant.

I don't care that much about OOP theory, but the pragmatic issues Objectify addresses seem to come up for people all the time. A year ago Steve Klabnik and a few other people were talking about this and I noticed it then how it was echoing James Golick's (the OP) posts about limiting ActiveRecord's role from a few years before that.

There basically seem to me to be three trends in discussion of scaling Rails: 1) "Rails can't scale" FUD, 2) DHH saying "just add hardware and/or caching", and 3) this idea of decoupling persistence from modeling, basically, reining in ActiveRecord, which I've heard from people like James Golick, Steve Klabnik, Gary Bernhardt, and I think Xavier Shay. Paul Dix wrote a great book about making Rails apps service-oriented, the Thoughtbot guys touch on it in their antipatterns book as well, and it's not exactly a coincidence that for many Rails apps the only gem more crucial than ActiveRecord is Delayed Job or Resque.

[stiff]

When I say "If you look at Rails itself" I do not mean you in particular, I mean in general for people wondering about the problem a good lesson is checking out the Rails code, similarly "a new skill to be learned" in the sense that it is different from traditional OO modelling most people come from. I know your blog and I've seen you discussing concerns in some other place, so I do appreciate your background. Maybe being irritated about bad ideas makes me come up more abrasive than usual.

Anyway, the whole discussion so far was about dealing with the problem of large (in terms of code size) models, so I assumed by "scalability" you mean scalability in terms of being able to handle very large code bases, not performance issues. I do not understand how the approach presented here would result in performance improvements? I've commented elsewhere on the problems associated with it, others did as well in a fairly convincing way I think. I do not deny that problems with scaling both in the performance sense and in the code size sense do exist, I just do not see how Objectify solves any of them and I do see how many problems it introduces.

As for breaking your app down into separate HTTP services, I agree this can be useful in some situations, but it is completely different from the approach outlined in Objectify, for one you still get a chance to do (almost) normal OO modelling and structure the code in a reasonable way, even if the message passing is done via HTTP and not simply via Ruby method calls.

[bcrescimanno]

FWIW, I'm not a Rails developer; so take my comments as you will.

I don't think the problem people seem to have with Objectify is that they see it as a totally invalid solution to a problem--and I agree with your assessment that many people see this problem as very real.

My own take is that I find it disingenuous to call it an Object-Oriented solution to the problem; it's not. That doesn't make it bad, invalid, or wrong. It rightly raises a few eyebrows to talk about effectively calling namespaced procedures as if it were the pinnacle of Object-oriented design.