Yeah, show me the EntitlementRepository and all its dependencies. There’s Users, UsersProfile, Address, BillingProfile, Subscription, SubscriptionSet, and Mailer. You might even have it down the the rbac level.

Glad it’s satire.

Great article. The overall idea is summarized by its closing statement:

"strive for overall system clarity as your principle pursuit

OP here - for what it's worth, this was the case on our application which was Rails 8. Some other gem or workflow may have been involved, but is highly unlikely.

It depends. Rails is great for rapid application development. You probably don't want to decouple at that early stage. But when your app struggles with slow responses and job management becomes increasingly difficult, you begin to see the flip side of the trade-off between ease of development and performance. This recently featured project, https://github.com/9001/copyparty, is extremely performant but foregoes many of the niceties of Rails. It uses the filesystem instead of a database and has no build step for assets. I'm not sure the solution is to push all queries into repositories, but it's quite easy to abuse the convenience of ActiveRecord by intertwining all the business logic and database access.

I love the series (and the "wat?" talk, of course - somewhat less the whole TypeScript desiderata of Ok, computer).

And yes, it is nicer to avoid expensive tests if you can help it. It has been my experience, however, that if you can use a slightly-more integrated test - which touches more parts of the system - you are likely to find more regressions and much quicker than if you subscribe to the notion of "testing one function with collaborators all around". It is academically very appealing, and your tests will be quite fast indeed - but they will be much harder to read and understand, and are always one "and_call_original" away from being useless.

As to decoupling from a framework in an ecosystem where, realistically, there is only one framework - and where, realistically, there are no deployment targets except for that framework - I don't believe this to be useful, sorry.

Yes, you can deploy your code into a cloud function (both AWS and GCP do Ruby cloud functions and you can get quite a bit of mileage out of it) but this is not an architecture you are likely to plan for - or need - until quite, quite late into the growth of a codebase. And even then - those runtimes have different constraints, so you may want to build a module which is accessible both from Rails and from such a cloud function.

What I don't like is the conversation of "you must decouple to decouple", which is not a way to advocate for something at all.

I doubt I agree with this statement. If a junior is causing a full table scan by doing a where(), I will teach them how to detect it - and how to avoid doing this in the future. If the idea of how a joint does applications is that a junior should be able to work with the codebase without being able to generate a SQL query of arbitrary complexity - that is a valid desire, but let's not call it "a better architecture", let's call it "I want cheap labour from people I don't trust and don't want to teach".

Maybe if the generation of those queries is from templates and it is the concern at hand - a better approach is using a restricted templating system like Liquid where all possible queries are canned and pre-generated via specific template helpers, but I doubt this mandates a Repository still.