Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building Modular Rails Applications: A Deep Dive into Rails Engines

panasiti.me

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#31

Post by fhub »

giovapanasiti wrote: post #12
mrinterweb wrote: post #9

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'v…

This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years

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.

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#32

Post by djfobbz »

mrinterweb wrote: post #9

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'v…

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! ;)

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#33

Post by nonconstant »

Octoth0rpe wrote: post #23
pqdbr wrote: post #10

Earlier quoted context omitted.

Rails is not only alive and well, but actually booming.

> 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.

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.

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#34

Post by jamesfinlayson »

ecshafer wrote: post #22
leptons wrote: post #17

Earlier quoted context omitted.

I've built numerous systems on AWS Lambda over the last 10 years, and have never once regretted it. YMMV.

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”.

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.

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#35

Post by burnt-resistor »

fhub wrote: post #31
giovapanasiti wrote: post #12

Earlier quoted context omitted.

This is exactly my experience. Most of the time people go to microservices for the wrong reason and they will regret that for years

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.

They're the people with guitar websites and say how "awesome" they are.

In truth, they're superficial technology terrorists.

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#36

Post by whstl »

stronglikedan wrote: post #19
whstl wrote: post #14

Earlier quoted context omitted.

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. Gi…

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.

As the sibling poster said, you probably misunderstood my point.

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

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#38

Post by whstl »

JohnBooty wrote: post #24
rco8786 wrote: post #20

Earlier quoted context omitted.

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.

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.

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.

Re: Building Modular Rails Applications: A Deep Dive into Rails Engines

#40

Post by mattgreenrocks »

burnt-resistor wrote: post #35
fhub wrote: post #31

Earlier quoted context omitted.

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.

They're the people with guitar websites and say how "awesome" they are. In truth, they're superficial technology terrorists.

Guitar websites?
Post reply on HN