Do you have any references that validate this?
Rails 'booming' on a 3 year time scale wouldn't surprise me, but would on a 10 year scale.
Rails is not at the peak of visibility (like it was in 2008-2014), it is not a "default stack for new products" but here's what we see: Rails startup just did a large IPO (Chime), another Ruby startup filed for IPO (Figma) Rails startup just posted a record ARR growth (bolt.new)
Lots of startups and lots of success stories. See https://evilmartians.com/events/startups-on-rails-in-past-pr...
Again, not the #1 or "default" choice, which is probably a good thing, because we are past the hype+disappointment cycle and on the pragmatic side of things.
The plugins can rely on all of the Laravelisms (auth, storage etc) and Filament allows them to easily draw app/admin UI.
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.
I'm talking about how monoliths can also fix such problems when they happen.
There's tools that make it easy, I'm still using a tool I built 10 years ago. Very little has changed except the addition of layers, which are also pretty easy and automatically handled in my dev tool.
All the Lambdas I write also run locally, and testing isn't an issue.
The only gripe I have with Lambda is when they deprecate older nodejs versions, and I am forced to update some of my Lambdas to run on current nodejs, which then leads to refactoring due to node module incompatibilities in some specific situations. But those are really nodejs problems and not so much Lambda problems, and it does get me to keep my apps updated.
YMMV.
In truth, they're superficial technology terrorists.
Concerns (in the broad sense, not ActiveSupport::Concern) can be separated any number of ways. The important part is delineating and formalizing the boundaries between them. For example, a worker running in Puma might instantiate and call three or four or a dozen different service objects all within different engines to accomplish what it needs, but all of that runs in the same Sidekiq thread.
Inserting HTTP or gRPC requests between layers might enforce clean logical boundaries but often what you end up with is a distributed ball of mud that is harder to reason about than a single codebase.
I would also never connect services without a queue unless the message can be discarded (then I can use a pub sub). Using http is one of the most amateurish ways I can imagine to connect two services that I wrote. Even the thought is cringe. Is this common?
You can have a "big, beautiful" Rails monolith codebase used by both Puma and Sidekiq queues etc, and that works well from most standpoints. But RAM usage will be pretty high and limit horizontal scaling.
Fixing this would probably require some changes at the language level, or at the module-loader level for some languages that use one.
Think about it from another angle. RAM is expensive when you're talking about cloud infrastructure at scale.
Or, think about it this way.
For a given compute budget, I can run X instances of Rails, or X times Y instances of a framework that uses less RAM. 100 instances of Rails versus 300 instances of Express or whatever.
Now, it still might be worth it to run Rails, because developer time is more expensive than cloud infrastructure. Or maybe you don't really need to scale. Or you could skip the cloud infrastructure and go bare metal, which is what Basecamp does last I checked.
I feel like the emphasis was on autoscaling parts of the app independently. (It’s telling that this has been forgotten and now we only remember it as “splitting up the app”.)
I also hate the agreement of maybe one day we might... as a justification for a new microservice. The number of times that premature optimization didn't pay off is far less than I've seen it come to be.
Microservice should be an exception, not the preferred architectural design pattern.
Sometimes I cynically think system architects like them because they make their diagrams look more important.
helle253•6mo ago
I recently migrated a featureset from one Rails project into another, as a mounted engine, and ensuring isolation (but not requiring it!) has been tremendously helpful.