[HN Gopher] Building Modular Rails Applications: A Deep Dive int...
___________________________________________________________________
Building Modular Rails Applications: A Deep Dive into Rails Engines
Author : giovapanasiti
Score : 177 points
Date : 2025-07-14 15:30 UTC (1 days ago)
(HTM) web link (www.panasiti.me)
(TXT) w3m dump (www.panasiti.me)
| helle253 wrote:
| I love Rails Engines, it's a very slick feature.
|
| 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.
| hk1337 wrote:
| I have been looking at using Rails Engines recently playing
| around with trying to get an idea off the ground.
| GGO wrote:
| Rails engines are one of the most underrated features that
| everyone should be using more.
| matltc wrote:
| Miss seeing rails in the wild
| pqdbr wrote:
| Rails is not only alive and well, but actually booming.
| Octoth0rpe wrote:
| > Rails is not only alive and well, but actually booming.
|
| 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.
| nonconstant wrote:
| We're experiencing a global peak of Ruby meetups
| (globally). About 800-900 meetups in the last 12 months as
| per https://rubyconferences.org/meetups/ I'm hosting
| probably the largest Ruby meetup in San Francisco, see
| https://lu.ma/sfruby
|
| 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.
| october8140 wrote:
| https://hnhiring.com/technologies/rails
| capevace wrote:
| The Filament package for Laravel lets you build similarly
| encapsulated ,,plugins", that are basically mini Laravel apps,
| that can be easily added to existing apps.
|
| The plugins can rely on all of the Laravelisms (auth, storage
| etc) and Filament allows them to easily draw app/admin UI.
| tommica wrote:
| Hmm, do you have some links/blogs to share about this - would
| be interested to know more.
| mrinterweb wrote:
| One of the reasons microservice architecture originally became
| popular was to break apart monolithic applications. In many
| cases, I bet a big driver was a lack of separation of concerns,
| and a more modular design was desired. There are many ways to put
| up walls in software to help make software more modular and self-
| contained. Rails engines are a good way to make more a rails app
| more modular. The number of times I've seen microservices created
| for the purpose of modularity (not scaling concerns), and the
| complexity that has brought has really soured me on
| microservices.
| giovapanasiti wrote:
| This is exactly my experience. Most of the time people go to
| microservices for the wrong reason and they will regret that
| for years
| whstl wrote:
| 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.
| stronglikedan wrote:
| 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.
| inopinatus wrote:
| 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.
| whstl wrote:
| As the sibling poster said, you probably misunderstood my
| point.
|
| I'm talking about how monoliths can _also_ fix such
| problems when they happen.
| the_sleaze_ wrote:
| 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.
| leptons wrote:
| I've built numerous systems on AWS Lambda over the last 10
| years, and have never once regretted it. YMMV.
| ecshafer wrote:
| Ive regretted 99% of the services Ive built in AWS lambda
| over the years. Everytime it gets more complex than a
| couple hundred lines of code over a few lambas I start to
| think "if this were just one service, development,
| deployments, cicd, testing, storage would all be simpler".
| leptons wrote:
| My deployments to Lambda are extremely simple. All I do
| is hit save in VSCode and the Lambda is updated. Change
| the env to prod and it deploys instantly to prod.
|
| 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.
| jamesfinlayson wrote:
| I inherited a Lambda application at one job - when I
| started it was probably 200+ Lambdas and it got to 128
| Lambdas. Lots of message queues, lots of Lambdas
| subscribed to queues where they ignored 99% of incoming
| messages... quite a mess. The Lambdas that are gone got
| repackaged into a SpringBoot application which thoroughly
| simplified things.
| fhub wrote:
| Some might, but I imagine some have left the company when the
| pain is really felt and are excited to do it all again at the
| next company.
| burnt-resistor wrote:
| They're the people with guitar websites and say how
| "awesome" they are.
|
| In truth, they're superficial technology terrorists.
| mattgreenrocks wrote:
| Guitar websites?
| nurettin wrote:
| I use multiple services for resilience. Example: With multiple
| services that have clear separation of concerns, you can debug
| and fix your processing layer without stopping the collection
| layer. You can update a distributor while workers wait and vice
| versa. This way I never have downtime anxiety. No regrets.
| zrail wrote:
| Separation of services is orthogonal to separation of
| concerns. There's nothing stopping you from having multiple
| entry points into the same monolith. I.e. web servers run
| `puma` and workers run `sidekiq` but both are running the
| same codebase. This is, in fact, the way that every
| production Rails app that I've worked with is structured in
| terms of services.
|
| 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.
| mrinterweb wrote:
| For your example, rails apps handle this case by default with
| job queues that are managed by the deployment separately.
| There is a way to force the job queue to process in the same
| process as your web server, but that's not the way most
| should be running prod rails apps. There usually isn't
| anxiety associated with rails app deploys, in my experience.
| rco8786 wrote:
| What can you not do in a monolith? You can still have async
| queues and different event processors that stop and start
| independently within a monolithic deployment.
| JohnBooty wrote:
| Speaking as a monolith fan, IMO/IME the main drawback is
| RAM usage per instance.
|
| 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.
| whstl wrote:
| Yep, that's a great point.
|
| Fixing this would probably require some changes at the
| language level, or at the module-loader level for some
| languages that use one.
| jt2190 wrote:
| > One of the reasons microservice architecture originally
| became popular was to break apart monolithic applications.
|
| 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".)
| bwilliams wrote:
| You can have a modular monolith with multiple entrypoints
| that enable autoscaling of independent "deploys".
| ch4s3 wrote:
| That's always made sense to me in theory, but practically
| speaking a lot of logical units of service just don't scale
| independently of your core service. Obviously this isn't
| always true but I think it's too easy to talk yourself into
| popping off new services and once you've built out the
| infrastructure for it and the incidental complexity is
| costly.
| mrinterweb wrote:
| Scaling concerns can be a legitimate reason for a
| microservice, but I think those scaling concerns should be
| proven and not assumed before a new microservice is born.
|
| 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.
| djfobbz wrote:
| I built my first SaaS back in 2009 on Rails 2.3. Fast forward
| to 2025, it's still running on Rails 2.3 LTS and Ruby 3.3.8,
| and it's still making money. No complaints here! ;)
| silasb wrote:
| I 100% agree which has led me in saying "modules >
| microservices" for our onboarding documentation.
| malkosta wrote:
| Offset-based pagination will be a problem on big tables.
| ethan_smith wrote:
| Cursor-based pagination (using a unique, indexed column like
| `created_at` with an ID tiebreaker) would be a more efficient
| alternative here.
___________________________________________________________________
(page generated 2025-07-15 23:02 UTC)