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

41–50 of 51 posts

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

#41

Post by the_sleaze_ »

whstl wrote: post #14
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

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…

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.

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

#42

Post by silasb »

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 100% agree which has led me in saying "modules > microservices" for our onboarding documentation.

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

#43

Post by tommica »

capevace wrote: post #8

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.

Hmm, do you have some links/blogs to share about this - would be interested to know more.

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

#44

Post by nurettin »

zrail wrote: post #16
nurettin wrote: post #15

Earlier quoted context omitted.

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.

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) c…

By concern I meant performing different actions and owning write access to different tables, not having completely separate code bases you seem to have construed for some reason.

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?

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

#45

Post by nurettin »

rco8786 wrote: post #20
nurettin wrote: post #15

Earlier quoted context omitted.

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.

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.

If by monolith you mean multiple processes that you can control separately, each with their own memory state, you can do anything you want with it. That's essentially multiple services.

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

#46

Post by rco8786 »

nurettin wrote: post #45
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.

If by monolith you mean multiple processes that you can control separately, each with their own memory state, you can do anything you want with it. That's essentially multiple services.

Monolith architectures are not constrained to running as a single process or on a single machine at all.

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

#47

Post by rco8786 »

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.

Does it? RAM is not particularly expensive

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

#48

Post by nurettin »

rco8786 wrote: post #46
nurettin wrote: post #45

Earlier quoted context omitted.

If by monolith you mean multiple processes that you can control separately, each with their own memory state, you can do anything you want with it. That's essentially multiple services.

Monolith architectures are not constrained to running as a single process or on a single machine at all.

Did you just reply to the first word?

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

#49

Post by burnt-resistor »

mattgreenrocks wrote: post #40
burnt-resistor wrote: post #35

Earlier quoted context omitted.

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

Guitar websites?

Rock-and-roll/metal band content congratulating themselves. They're "so cool".

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

#50

Post by JohnBooty »

rco8786 wrote: post #47
JohnBooty wrote: post #24

Earlier quoted context omitted.

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.

Does it? RAM is not particularly expensive

Sure, you can get 32GB of RAM for less than $100, but that's not the relevant thing to think about.

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.

Post reply on HN