Hexatetrahedral Rails(blog.julik.nl)
blog.julik.nl
Hexatetrahedral Rails
https://blog.julik.nl/2025/07/hexatetrahedral-rails
20 comments
The justifications for this kind of thinking are explained very well and in great detail in the Destroy All Software screencast series by Gary Bernhardt.
Yes, it is a good idea to decouple your application from the framework. Yes, it is a good idea to write your own functions which wrap persistence layer library functions. Yes, it is a good idea to drive out the design of the system with automated tests, and to avoid having to test behaviour with more expensive integrated tests where possible.
Yes, it is a good idea to decouple your application from the framework. Yes, it is a good idea to write your own functions which wrap persistence layer library functions. Yes, it is a good idea to drive out the design of the system with automated tests, and to avoid having to test behaviour with more expensive integrated tests where possible.
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.
Every Rails project I've been involved with has had two phases:
The first phase was being amazed that we got basic functionality up and running so fast
The second phase was feeling like we were spinning our wheels because we were always dealing with some performance issue or some complexity explosion that occurred when we stepped outside of the bounds of a simple low volume CRUD app where Rails excels.
The first phase was being amazed that we got basic functionality up and running so fast
The second phase was feeling like we were spinning our wheels because we were always dealing with some performance issue or some complexity explosion that occurred when we stepped outside of the bounds of a simple low volume CRUD app where Rails excels.
That does not mirror my experience. What I did see a lot was either spinning wheels because multiple people had divergent ideas about how the complexity should be managed, or spinning wheels because people on the project did not want to work with Rails at all and just wanted a rewrite of everything in something else.
Complexity does not have to be an explosion, but it always will be if the team designs in a way that is not coherent - and coherence is hard to achieve.
Complexity does not have to be an explosion, but it always will be if the team designs in a way that is not coherent - and coherence is hard to achieve.
That project is a treat - but it's effectively an FTP server, so most of its useful data will be in the files it hosts themselves. And it's deliberately built for being run off a single server. I had a similar project a long while ago which would "wrap" an FTP server with a WeTransfer-like web UI, and it also had no database - since none was needed.
"No build step for assets" is how I do my Rails apps these days if I can help it, luckily modern browsers allow for that to a great extent.
"No build step for assets" is how I do my Rails apps these days if I can help it, luckily modern browsers allow for that to a great extent.
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.
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 think the point of decoupling from the framework is that it's a good proxy for factoring code into a form in which it remains economically feasible to test it with sufficient rigour. It's not because you actually want to switch out the framework at some point to some other named framework. You are likely however to switch out the framework with another version of the same framework, i.e., a Rails major version bump, and we've seen over time that this is a genuine pain point for thousands of companies of all sizes, because typically people couple their code to the framework.
Also, none of this is specific to Rails. I have the same concerns with Yesod, although it's easier to get unstuck in the latter case because of the typechecker.
Also, none of this is specific to Rails. I have the same concerns with Yesod, although it's easier to get unstuck in the latter case because of the typechecker.
In case anyone else is wondering about the analogy:
https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd462...
https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd462...
> No, you shall not do a User.where directly, you have to do a
> UsersRepository.find_all_with_email(...).
Even that seems weird to me. If want to load objects, I want to load them from a particular repository, not a class of repositories (which the upper-casing of `UsersRepository` suggests).
As soon as your app needs to talk to more than one data source, this business where data is tightly coupled to a particular datasource by the framework makes a big mess.
But that's why I don't use Rails in the first place.
Even that seems weird to me. If want to load objects, I want to load them from a particular repository, not a class of repositories (which the upper-casing of `UsersRepository` suggests).
As soon as your app needs to talk to more than one data source, this business where data is tightly coupled to a particular datasource by the framework makes a big mess.
But that's why I don't use Rails in the first place.
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.
Glad it’s satire.
You mean the `def user_repository_provider` on the controller I believe?
I'm so relieved this is a parody and critique.
I only clicked through out of morbid curiosity: the software architecture version of watching a train wreck.
I only clicked through out of morbid curiosity: the software architecture version of watching a train wreck.
Repositories do make sense tho. If my interface is raw ActiveRecord, then you can't be mad at your junior for making a full table scan with "where" on every request.
I don't know why would you replace AR to make a repository if you can build it on top of AR.
I don't know why would you replace AR to make a repository if you can build it on top of AR.
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.
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.
> "I want cheap labour from people I don't trust and don't want to teach".
Uhm...no? This is just about keeping things DRY. Do you pride yourself in writing an SQL query from scratch every time you need a query database? Abstracting `where()` and co away makes life easier for everyone to stay on the right path.
Uhm...no? This is just about keeping things DRY. Do you pride yourself in writing an SQL query from scratch every time you need a query database? Abstracting `where()` and co away makes life easier for everyone to stay on the right path.
Some historical context and one of the more provocatively titled writeups during the last time this was widely debated: https://dhh.dk/2014/test-induced-design-damage.html
Great article. The overall idea is summarized by its closing statement:
"strive for overall system clarity as your principle pursuit
"strive for overall system clarity as your principle pursuit
This is false. At least not in Rails 7+ (haven't tested earlier), user.log_entries will return exactly what you'd expect (one instance of LogEntry).