- I wanted to make an index page where a user could make edits to the items being displayed and make regular show/edit pages for the item so if a user was on that page they could edit it. This is actually really useful: a user can bookmark the page for a specific item, or open it in a new tab, or in general do things browsers let you do but apps struggle with. Making two different edit components would be stupid, and I thought this would be one of those things that I could do better in React than in Rails. After looking around a bit I quickly found that if I used standard REST-y routes and wrapped the key parts of the view with turbo frames I could get exactly what I wanted, and it worked out seamlessly. In general, I've found that Rails' heavy emphasis on REST was a good architectural choice, and every time I disagreed with it and went another way I ended up regretting that choice and reverting to REST.
- In the Java world, you typically have thin models + a service layer which has the business logic. This is apart from other layers such as Repo/DAO etc, which I was already replacing with ActiveRecord, but I was initially resistant to putting all of my business logic in the models, especially if it involved logic across them. But it also hurt discoverability. I was working on a project I was expecting other people to work on with me, and I wanted to make it easy for them to figure out what they could do with a model object. The solution to this came from DHH himself. I've lost a link for this, but he said that if you make service objects, you should add a method on the model that acts as a way to reach the service. This keeps the model "fat" while also separating out logic into simple, unit-testable classes.
One of the smaller things I appreciate is keeping all of the routing details in rails routes. I know other frameworks like Django also do this, but I really didn't like this about most Java frameworks and microframeworks in other languages.
In general, if you're interested in seeing how to architect Rails apps, I say study how 37Signals does it. Playing around with Basecamp convinced me of the practicality of the Rails way and taught me a lot of interesting and useful patterns.
This is news to me. Is this really true?
Longtime rails dev here. The reason smaller companies are using it is because you can move much faster working on a full stack rails app that gives you SPA-like functionality without needing to incur the performance or operational cost of a dedicated front end.
I've worked for both rails shops and JS shops, and the productivity achieved with Rails is staggering compared to React in a small team environment. Guillermo Rauch tweeted a few months back that SPAs were a zero interest-rate phenomenon and I completely agree. Just because a bunch of companies jumped on the JS hype train doesn't mean that they were all making the right decision.
Guillermo Rauch is selling Vercel, whose strategy includes first-class tooling for SSR, convincing people to move their SPA to SSR, and then locking them in on their platform.
[1] https://rauchg.com/2014/7-principles-of-rich-web-application...
Referring to SPAs as a "zero-interest-rate phenomenon" implies that SSG/SSR models are more efficient in terms of financial cost of deployment. I don't agree this is necessarily the case, and I think SPAs can be developed and deployed sanely and cheaply also.
Vercel is doing some amazing things, but it's also innovating in ways that occasionally lead to "lock-in", in the sense that moving away from Vercel would involve a lot of friction. So I think it's fair to point out that you have a financial interest in convincing people to adopt delivery models that your business streamlines.
Anecdotal I know, but from the moment that it appeared on my resume in 2012 it's been non-stop. Probably 80% of everything I hear about.
Ruby and it's ecosystem brings the closest thing to natural Aspect Oriented Programming that I've seen in the wild, which is why it's so much more productive than everything else I've tried.