| 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. |
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.