Taming Large Rails Applications with Private ActiveRecord Models(kellysutton.com)
kellysutton.com
Taming Large Rails Applications with Private ActiveRecord Models
https://kellysutton.com/2019/10/29/taming-large-rails-codebases-with-private-activerecord-models.html
4 comments
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.
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.
"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.
> 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.
>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.
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.
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
This is the DAO pattern, welcome to 1999 Ruby.
https://www.baeldung.com/java-dao-pattern
https://www.baeldung.com/java-dao-pattern
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.
Rails made a choice to use the active record pattern instead. This article is about adapting an existing application to a new pattern.
I'm glad they mentioned ROM and Sequel. But of course, pragmatism beats favoritism.
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.