3 ms·

I've been doing fulltime Rails dev for some 15+ years. Rails (and Ruby) make tradeoffs, or just inherently have downsides that many newer frameworks, libraries

by berkes 3y ago

I've been doing fulltime Rails dev for some 15+ years. Rails (and Ruby) make tradeoffs, or just inherently have downsides that many newer frameworks, libraries and languages solve, or solve differently. For me, the most prominent are Rubys' dynamic typing and Rails' black magic. But my biggest gripe is how Rails lacks a space for business logic. Sure, you can bolt something on yourself. Or just throw it all throughout the http, storage and rendering layer willi-nilli. This has caused so many of the codebases i worked on, to be unmaintainable, untestable and therefore legacy that I can certainly blame it on the framework. I've worked on many go, rust, typescript, php and ruby-no-rails systems to be ever more certain about this. Many frameworks lack this area, and almost all quickly degrade into spaghettis. I've come to like DDD, hexagonal and clean architecture for solving this. Most are perpendicular to Rails. So, i'm certain that contributor to the lack of popularity of Rails is how hard it is to build maintainable, testable, clean projects in it.

gls2ro 3y ago
What is an example of a framework that offers a space for business logic?
- berkes 3y ago
  I'd say it's a gradient. With Rails(ish) on one end, via, Nest.js and Laravel (DI), Hanami to Event Sourcing, CQRS or Hexagonal setups on the other The latter, in my experience, is best. It's a "no framework" setup really. Where you organize code according to a "framework" that's no code, but architecture, conventions, rules, and design patterns. Where code reuse goes via libs, put aside behind abstractions. I consider the question "what framework offers good architecture (for maintainability, DDD or business logic)" a somewhat wrong question because in it lies a strong opinion of what a framework is. And such frameworks are counter to what you want: you don't want these frameworks.
- amcvitty 3y ago
  Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code. [1] https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html
Toutouxc 3y ago
> But my biggest gripe is how Rails lacks a space for business logic. You can literally create a directory called app/my_actual_app and put all your business logic in there, Rails will even autoload it for you. IMO it’s the sudden change from the “we’ll hold your hand every step of the way and offer tools and workflows for everything” web part (controllers, routing, ORM) to the “go and build your goddamn app” dealing with business logic. So many (especially new) devs try to stay in the cozy zone of having a nice name for everything at all costs, so they try to cram everything into “services” and “decorators” and “interactors” (yuck) and they’ll build business logic out of callbacks on ActiveRecord models and overload the poor things with dozens of “concerns” instead of, you know, going and building a goddamn Ruby app.
lylo 3y ago
Re: DDD and business logic, I’d recommend reading https://dev.37signals.com/vanilla-rails-is-plenty/ https://dev.37signals.com/vanilla-rails-is-plenty/
- berkes 3y ago
  I've read that and tried it. I hate it. This recent article has some alternatives https://blog.appsignal.com/2023/05/10/organize-business-logic-in-your-ruby-on-rails-application.html https://blog.appsignal.com/2023/05/10/organize-business-logi... Their main argument against the first piece is: > One problem with fat models is that unless you are really disciplined in your code hygiene, they can tend towards an assortment of code smells And I wholeheartedly agree. With the addition that "code hygiene" if not enforced or encouraged, is always one of the first victims under stress. And every (successful) project will see such stress. With Rails you have to spend extra effort to keep doing "the right thing", whereas is should cost cost less effort to do that, and extra effort to "do the bad thing".

by berkes 3y ago

gls2ro 3y ago

What is an example of a framework that offers a space for business logic?

berkes 3y ago
I'd say it's a gradient. With Rails(ish) on one end, via, Nest.js and Laravel (DI), Hanami to Event Sourcing, CQRS or Hexagonal setups on the other The latter, in my experience, is best. It's a "no framework" setup really. Where you organize code according to a "framework" that's no code, but architecture, conventions, rules, and design patterns. Where code reuse goes via libs, put aside behind abstractions. I consider the question "what framework offers good architecture (for maintainability, DDD or business logic)" a somewhat wrong question because in it lies a strong opinion of what a framework is. And such frameworks are counter to what you want: you don't want these frameworks.
amcvitty 3y ago
Phoenix (web framework for elixir) famously has the meme out there that “Phoenix is not your application”, with various articles etc explaining that the web interface should be a layer on top of the application code. They made a big deal of adding Contexts [1] as part of the scaffold which isn’t much more than a directory to put core app code. [1] https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html

Toutouxc 3y ago

> But my biggest gripe is how Rails lacks a space for business logic. You can literally create a directory called app/my_actual_app and put all your business logic in there, Rails will even autoload it for you. IMO it’s the sudden change from the “we’ll hold your hand every step of the way and offer tools and workflows for everything” web part (controllers, routing, ORM) to the “go and build your goddamn app” dealing with business logic. So many (especially new) devs try to stay in the cozy zone of having a nice name for everything at all costs, so they try to cram everything into “services” and “decorators” and “interactors” (yuck) and they’ll build business logic out of callbacks on ActiveRecord models and overload the poor things with dozens of “concerns” instead of, you know, going and building a goddamn Ruby app.

lylo 3y ago

Re: DDD and business logic, I’d recommend reading https://dev.37signals.com/vanilla-rails-is-plenty/ https://dev.37signals.com/vanilla-rails-is-plenty/

berkes 3y ago
I've read that and tried it. I hate it. This recent article has some alternatives https://blog.appsignal.com/2023/05/10/organize-business-logic-in-your-ruby-on-rails-application.html https://blog.appsignal.com/2023/05/10/organize-business-logi... Their main argument against the first piece is: > One problem with fat models is that unless you are really disciplined in your code hygiene, they can tend towards an assortment of code smells And I wholeheartedly agree. With the addition that "code hygiene" if not enforced or encouraged, is always one of the first victims under stress. And every (successful) project will see such stress. With Rails you have to spend extra effort to keep doing "the right thing", whereas is should cost cost less effort to do that, and extra effort to "do the bad thing".