I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
embrace what Rails is and isn't and build a "majestic monolith"
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.