[HN Gopher] Hexatetrahedral Rails
       ___________________________________________________________________
        
       Hexatetrahedral Rails
        
       Author : julik
       Score  : 29 points
       Date   : 2025-07-27 12:56 UTC (3 days ago)
        
 (HTM) web link (blog.julik.nl)
 (TXT) w3m dump (blog.julik.nl)
        
       | aaroninsf wrote:
       | In case anyone else is wondering about the analogy:
       | 
       | https://sketchfab.com/3d-models/hexatetrahedron-a0ef716cd462...
        
       | static_void wrote:
       | 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 wrote:
       | > 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 wrote:
         | 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.
        
       | ryandv wrote:
       | 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
        
       | pqdbr wrote:
       | 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).
        
       | yakshaving_jgt wrote:
       | 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 wrote:
         | 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.
        
           | Aurornis wrote:
           | 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.
        
       | 0x457 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-07-30 23:01 UTC)