This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Keep your ActiveRecord models manageable the Rails way

updated over 4 years ago; latest suggestion over 4 years ago

Rails is brilliant! It makes it very easy and enjoyable to start a new project. However, as your application grows, you will eventually have to come off the Rails or your codebase will become completely unmanageable. Everyone knows that.

You'll need presenters and a service layer, including role and use-case objects. DCI will be great too or, alternatively, you can go Hexagonal. After all, the web is just a delivery mechanism, the database is a mere persistence strategy and, of course, Rails is a detail.

But… Wait a minute! Is that really true? Does the Rails way no longer work when your application becomes large? How is it, then, that Rails claims to be “optimised for sustainable productivity”?

In this talk, we'll revisit the patterns and conventions that Rails encourages. We'll push them to the limit and see how the maintainers of large Rails applications keep their models manageable without needing to derail. We'll also discuss the trade-offs of being on and off the Rails. And, maybe, you'll finally learn how to stop worrying and love the Rails way!


  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 4 years ago

    Do you think that Concerns (e.g. mixin modules) are a first step towards actually breaking our models up? The tradeoff that Andrew describes where the full definition of our model is split across multiple files is maybe a secret push towards this as it makes us think "Oh! This model does a lot and it's hard to find" and one response to that is to push it further and actually have new objects that do the concern stuff instead (the other response is to just stuff it all back in one file).

    Of course, I'm assuming that you think splitting models up is a good thing, maybe you don't. I'd be interested to hear you discuss something along those lines (no matter your opinion).

  • The proposal author responds over 4 years ago

    I think it doesn't go against the anonymous policy to say that I'm the author of these three proposals (which are variations on the same subject):

    During the last six months I've been researching about the big-models issue in Rails. There's a fair amount of buzz in the community about how to deal with this problem and I thought it would be interesting to study in depth each different view.

    James: This talk won't be necessarily a refutation of anything but rather a exploration of the "Rails way" as a sustainable approach in complex applications. And, yes, I plan to show some representative examples.

    Andrew: Concerns will definitely be part of the talk and, as with the other patterns I'll present, I plan to discuss the trade offs of applying them in different scenarios.

    Thanks for your input, guys!

  • B14001f2b40640dd6cb63f0e8f1f4869 Andrew White suggests over 4 years ago

    I don't whether you're planning to use the idea of "concerns" (an idea that DHH has put forward as a response to DCI, etc.) but one problem with this approach is that you can easily end up with a model's definition spread across multiple files and developers unfamiliar with the codebase can find it hard to track where the implementation of a method is. It might be good to show how and when it could be used and when it shouldn't be.

  • B68ce3695bb8dc29b9f9cb0dc0b721a5 Murray Steele suggests over 4 years ago

    It seems like there is some crossover between this talk and this one about patterns for large AR models. Do you think you can explain why your talk is different to that one, to help people decide when voting.

    We could also put you in touch with the other proposer to work out what cross-over there might be, and potentially work the two talks into one?

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 4 years ago

    Is it fair to say that this presentation is a refutation of some of the "DCI" or "OO" directions that some Rails developers are trying to move towards? Am I right in surmising that your basic argument is that Rails does provide mechanisms to manage complexity? If so, that could be interesting.

    I'm assuming that you'll be drawing on some experience of a long-lived Rails application; if that's the case, it'd be useful to know the "scale" of this app - in terms of number of models, age, that sort of thing.