- Fat models (huge number of hooks, scopes, many methods stuffed inside in the name of "domain-driven design", etc)
- Fat controllers (huge number of shared methods, hooks, shared variables and hooks, concerns, etc)
- Fat views/helpers/templates
In multiple years of working with Ruby (+/- Rails) - there is one talk that changed my whole mind of scaling systems - aka ways to build the majestic monolith [1]. And I believe the author of that talk would be laughing silently at this post right now, thinking, "I know what you're talking about".
Check out those slides, and check the codebase. This is not a Ruby problem. Splitting things mindlessly into microservices, trying to go "fully functional" (answer: nope, nothing in the world is pure or perfect), everything has trade-offs.
- Fat models (huge number of hooks, scopes, many methods stuffed inside in the name of "domain-driven design", etc)
- Fat controllers (huge number of shared methods, hooks, shared variables and hooks, concerns, etc)
- Fat views/helpers/templates
In multiple years of working with Ruby (+/- Rails) - there is one talk that changed my whole mind of scaling systems - aka ways to build the majestic monolith [1]. And I believe the author of that talk would be laughing silently at this post right now, thinking, "I know what you're talking about".
Models, Models, Everywhere by Chris Griego: https://speakerdeck.com/u/cgriego/p/models-models-every-wher...
Check out those slides, and check the codebase. This is not a Ruby problem. Splitting things mindlessly into microservices, trying to go "fully functional" (answer: nope, nothing in the world is pure or perfect), everything has trade-offs.
[1] Majestic Monolith: https://m.signalvnoise.com/the-majestic-monolith-29166d02222...