You can "componentize" various parts of Rails and make it less of a monolith by using Rails engines.
I do it by having a new folder "components" on the Rails root and adding `gem 'name_of_component', path: 'components/name_of_component'` which looks like a vendored gem.
Rails engines has the ability to "isolate_namespace" which is I think the default for a new engine. This is where you can avoid global name spacing issues where each component can be thought of separately. Effectively, you have something _kinda_ like a microservice but it runs as a monolith. And if you need you can have each component depend on others so long as you don't wind up in a loop.
Note: I have a component "common_models" which is just for commonly used items across various components. The main app should have nothing in it's Rails.root/app since you instead have components.
I'm not related to this but here's a basic idea: https://cbra.info . (Pretty sure the author of this page made the Railsconf talk that inspired me to move to this years ago.)
I do it by having a new folder "components" on the Rails root and adding `gem 'name_of_component', path: 'components/name_of_component'` which looks like a vendored gem.
Rails engines has the ability to "isolate_namespace" which is I think the default for a new engine. This is where you can avoid global name spacing issues where each component can be thought of separately. Effectively, you have something _kinda_ like a microservice but it runs as a monolith. And if you need you can have each component depend on others so long as you don't wind up in a loop.
Note: I have a component "common_models" which is just for commonly used items across various components. The main app should have nothing in it's Rails.root/app since you instead have components.
I'm not related to this but here's a basic idea: https://cbra.info . (Pretty sure the author of this page made the Railsconf talk that inspired me to move to this years ago.)