News for hackers. Stuff that matters.

A comment on Building Modular Rails Applications: A Deep Dive into Rails Engines. Parent comment

Re:Building Modular Rails Applications: A Deep Dive into Rai... by whstl on Monday July 14, 2025 @02:28PM (#44563586)
Different sections of an app can use different databases, if the bottleneck is in the database.

Different routes can be served by different servers, if the bottleneck is in CPU usage.

Different async tasks can run on different task runner services, if the problem is tasks competing with each other.

Different test suites can run for different sections of the app, if the problem is with tests taking too long to run.

Github and others even allow specific subfolders to be "owned" by different teams.

What else is there? Even slowness of compilation and/or initialization can be alleviated, depending on the language or framework.

[ Parent | on HN ]
Re:Building Modular Rails Applications: A Deep Dive into Rai... by stronglikedan on Monday July 14, 2025 @03:46PM (#44564474)
I think the point is that all of that adds complexity that is often unnecessary - a premature optimization if you will. It's like a hammer, and everything looks like a nail to a lot of people.
[ Parent | on HN ]
Re:Building Modular Rails Applications: A Deep Dive into Rai... by inopinatus on Monday July 14, 2025 @04:44PM (#44565022)
GP isn’t oppositional, they listed runtime constructs that all run off a single monolith. The point being you don’t need so-called microservices for flexibility in the production environment.
[ Parent | on HN ]
Re:Building Modular Rails Applications: A Deep Dive into Rai... by whstl on Tuesday July 15, 2025 @05:23AM (#44569417)
As the sibling poster said, you probably misunderstood my point.

I'm talking about how monoliths can also fix such problems when they happen.

[ Parent | on HN ]
Re:Building Modular Rails Applications: A Deep Dive into Rai... by the_sleaze_ on Tuesday July 15, 2025 @10:33AM (#44571558)
Old incompatible library versions; dependency hell, security SLAs. Old company couldn't get off of Rails 3 for a multitude of reasons and splitting off microservices was a good decision. Syncing state across the services turned into its own barrel of monkeys, but was better overall.
[ Parent | on HN ]