Taming Large Rails Applications with Private ActiveRecord Models

https://kellysutton.com/2019/10/29/taming-large-rails-codebases-with-private-activerecord-models.html

by vinnyglennon • 7 years ago

29 8 7 years ago

I think this is a wise approach for large Rails applications, but this just looks like the Repository pattern to me, with ActiveRecord used as the db interaction layer

cooljacob204• 7 years ago

So this is really just hiding active record's methods in a model from the rest of the App?

I don't really understand why this would be an advantage in a large app.

It's more explicit, but then you have to slow down and add all those wrappers for active record stuff. I can also see it getting annoying/confusing if you have a mix of normal models and these models in an app that you are not familiar with.

When I think of and create a model I think of active record as part of that public interface. And unless I want to restrict stuff I would want the default to be exposed.

rawburt2• 7 years ago

"I don't really understand why this would be an advantage in a large app." They make quite a few points in the article:

The tangle of dependencies, callbacks, and relationships can grind your entire engineering organization to a halt.
Why do we want encapsulation? As an organization grows, any public interface will eventually be used.
So we start to take a defensive approach to modeling, only making public what we are sure that we can support. This makes these models easier to support because they have a smaller surface. They are easier to change internally, too, because there are fewer different uses.
It has also helped teams collaborate and create contracts for interactions.

"but then you have to slow down and add all those wrappers for active record stuff" you also have to slow down to resolve technical debt and deal with collaboration, among other things. It seems that the approach they describe is giving them a positive opportunity cost. There are always pros and cons.

"And unless I want to restrict stuff I would want the default to be exposed" the article explicitly says they wanted to restrict stuff.

justbaker• 7 years ago

I don't really understand why this would be an advantage in a large app.

My best guess is trying to limit instances of AR models, encapsulating them in a new data access pattern versus traditional Active Record/ORM; in other words, misusing AR against how it was designed.

mosselman• 7 years ago

I agree. It just makes it harder to reason about what is going on and what will happen when you call methods.

A far better approach is to put related methods in concerns. When you do this based on features, lets say a concern called "SyncToTrello" that contains all the methods on lets say a "Task" model that are related to syncing to Trello. So when I have to refactor or debug the sync, I just open up the concern and look at the handful of methods that are related to just that. Rather than having to scroll through a 500+ loc Task model.

Using concerns has been a great way to tackle growth in our Rails application.

rawburt2• 7 years ago

I'm glad they mentioned ROM and Sequel. But of course, pragmatism beats favoritism.

briandilley• 7 years ago

This is the DAO pattern, welcome to 1999 Ruby.

https://www.baeldung.com/java-dao-pattern

bradstewart• 7 years ago

It's not that Ruby has never heard of this pattern, the article even mentions libraries that implement it (ROM, Sequel).

Rails made a choice to use the active record pattern instead. This article is about adapting an existing application to a new pattern.

Taming Large Rails Applications with Private ActiveRecord Models

Related Stories