I worked on a couple of production apps in Rails at the start of my career. It was the first way I learned to make web applications. Rails works as advertised

I worked on a couple of production apps in Rails at the start of my career. It was the first way I learned to make web applications. Rails works as advertised and is great at what it does, but I think ultimately the conventions-obsessed nature of the community, that is often so helpful, has settled on some patterns that make the Rails approach more bother than it's worth with other good options out there. Often touted for being able to scale business logic and developer productivity at the expense of runtime performance, I see some serious issues with the claimed strengths. - The powerful active record pattern and accompanying library makes it easy to pile on coupling between business logic and database access code. - Ruby doesn't give you a straightforward way to protect against mutation, which leads to some real debugging nightmares at the worst of times. - Rails conventions openly disregard low hanging fruit best practices of OOP like the SRP, and make it difficult to design code that follow these practices without straying outside the well trodden conventions (hi again Active Record). - Rails provides configuration-like interfaces that don't feel like you're calling Ruby code. They are convenient, but offload a big cognitive burden in the name of convenience whenever you need to problem solved something that's not a garden-variety bug. Ultimately I made the time investment to try some other approaches and have been finding that it's possible to get much of the productivity of Rails at the (arguably worthwhile) cost of a bit of extra typing up front. If you know Ruby well already and have some business goals with some urgency behind them, certainly a great move. If you are earlier career and looking to invest in a productive skills set, you may be better served to consider a few different options.