Disclaimer: I haven't used Rails since around 3, but my assumption is the DX hasn't changed too much. Plus if Rails N was marketed at Rails "N-1" devs, then new

Disclaimer: I haven't used Rails since around 3, but my assumption is the DX hasn't changed too much. Plus if Rails N was marketed at Rails "N-1" devs, then new devs coming in late have a lot of learning to do. > avoid doing unusual things If by "unusual" you mean "not the Rails way", then this makes sense. But the problem is, the Rails way doesn't always line up with the way an experienced programmer might want to do something. In the specific example of fetching data from a DB - an experienced programmer might intuitively avoid multiple round-trips to the DB, and want to find the appropriate hook point(s) in a request handler to optimise this. Making 20 requests for 20 models is "unusual". Rails doesn't make things like this easy. It's quite opinionated on how you should work. The core assumption in play here is that databases will either be fast, or can be made faster, essentially externalising the problem. Or if you want to address this - find a Gem to do it, or dive into the layered guts of it to figure it out. Related - if I recall correctly, foreign keys were not deemed an important enough feature for inclusion in Active Record, and the Rails way is to embed the logic for joins into your models rather than the database. I'm sure many of us here could name several scenarios where this is just plain wrong.