3 ms·

Hexatetrahedral Rails

33 points by julik 1y ago

aaroninsf 1y ago
In case anyone else is wondering about the analogy: https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd4624d93b27389b30455078d https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd462...
static_void 1y ago
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.
TOGoS 1y ago
> 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.
- reactordev 1y ago
  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.
  - julik 1y ago
    You mean the `def user_repository_provider` on the controller I believe?
ryandv 1y ago
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 https://dhh.dk/2014/test-induced-design-damage.html
- andrelaszlo 1y ago
  Great article. The overall idea is summarized by its closing statement: "strive for overall system clarity as your principle pursuit
pqdbr 1y ago
The article has this gist: user.log_entries.delete_all user.log_entries.create!(message: "User account reset") user.log_entries #=> [], will be empty until reloaded 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).
- deleted 1y ago
  [deleted]
- julik 1y ago
  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.
yakshaving_jgt 1y ago
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.
- reedlaw 1y ago
  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 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.
  - Aurornis 1y ago
    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.
    - julik 1y ago
      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.
0x457 1y ago
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.
- julik 1y ago
  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.
  - 0x457 1y ago
    > "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.

33 points by julik 1y ago

In case anyone else is wondering about the analogy: https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd4624d93b27389b30455078d https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd462...

static_void 1y ago

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.

TOGoS 1y ago

> 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.

reactordev 1y ago
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.
- julik 1y ago
  You mean the `def user_repository_provider` on the controller I believe?

ryandv 1y ago

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 https://dhh.dk/2014/test-induced-design-damage.html

andrelaszlo 1y ago
Great article. The overall idea is summarized by its closing statement: "strive for overall system clarity as your principle pursuit

pqdbr 1y ago

The article has this gist: user.log_entries.delete_all user.log_entries.create!(message: "User account reset") user.log_entries #=> [], will be empty until reloaded 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).

deleted 1y ago
[deleted]
julik 1y ago
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.

yakshaving_jgt 1y ago

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.

reedlaw 1y ago
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 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.
- Aurornis 1y ago
  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.
  - julik 1y ago
    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.

0x457 1y ago

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.

julik 1y ago
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.
- 0x457 1y ago
  > "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.