DEV Community

Rails: The Struggle Is Real

Sean Walker on October 15, 2018

I don’t know how many hours I’ve lost to searching for what should be the easiest thing but instead I wind up scratching my head because I’m forc...

Read full post

Brian Vogelgesang • Oct 16 '18 • Edited

Is this some clickbait article to plug your new framework? Maybe you don't understand Rails? None of your points are flushed out, or in my opinion actually point to some of the issues Rails does have.

AR Callback Hell
Just because you can use those hooks, doesn't mean you should. Any PR I review that doesn't have a good reason for a before/after hooks would get rejected. Create explicit objects to handle your business logic, don't stuff them in the model where they get executed any time someone wants to create or update a DB object.

If you're in callback hell, it's because you made poor architecture decisions.

ERB
What is so complex about ERB, it's no different from any templating language I've used. You write HTML, and when you want to escape and execute code, you use <% insert_code_here %>.

"If I had a nickel for every time I closed an ERB tag due to editor malfunction..."
Maybe you should learn how to use your text editor

AR Syntax
current_user.todos.includes(:tags).where(completed: true).order(created_at: :desc).limit(30)

Do you know what SQL it takes to create the above AR Syntax?

SELECT *
FROM todos
WHERE completed_at is true AND user_id is $user_id
ORDER BY created_at desc
LIMIT 30;

Are you complaining that AR is too complicated for you? I'd say it's a hell of a lot cleaner and easier.

And yes, actually, the practice for any up-to-date rails application is to use a Serializer, which will eager load your associations if they're requested and let you abstract your response where it belongs, outside of the controller.

If you'd done any light reading on Rails, you'd take advantage of the things it offered, likes scopes, serializers, and pagination...

Serializer:

class TodoSerializer < ActiveModel::Serializer
  attributes :title, :description, :completed

  has_many :tags
end

Controller:

def completed_todos
  render json: Todo.where(completed: true), include: :tags
end

It literally requires that to return a JSONAPI compliant response with ActiveModel Serializers and Kamanari.

Your arguments are pretty moot, but maybe it's because you're trying to plug your framework. You would have done a much better job if you just explained the benefits of what your offering, without trying to shit on something.

Sean Walker • Oct 16 '18

I had to do a double take because I thought you were DHH for a second.

Thanks for taking the time to teach me all of these things! I needed it!

Adrien Poly • Oct 16 '18

I am sorry but if your goal is to advertise for your new framework why do you start by criticizing others👎👎👎👎👎.
Just spend more time writing about the benefits.
I read your GH project and I have no clue why your Framework would be better suited for my job. In which case does it bring a benefits etc.
Or at least you could take a Rails way of doing things and put side by side your way of doing things

Mihai Târnovan • Oct 16 '18

Are you trolling or just link-baiting? You don't even need to define a Serializer for this...

current_user.todos
  .includes(:tags)
  .where(completed: true)
  .order(created_at: :desc)
  .limit(30)
  .to_json(only: [:name], include: :tags)

Wayne • Oct 16 '18 • Edited

To be fair ERB isn't a Rails thing, it's the standard Ruby templating language, and I see it as really no different than most other standard templating languages.

Sean Walker • Oct 16 '18

This is true, something like slim or haml could solve that problem at least.

Alex Reilly • Oct 16 '18

I'm getting into rails at work right now and I have a lot of the same gripes, but I've also only been using it for a couple weeks so I'm hoping concepts will come together with more experience

Pankaj Doharey • Oct 16 '18

I personally think not to spoil your mind with rails MVC architecture, it doesnt hold long beyond a basic blog, it breaks down easily even under a moderately larger app. The conventions are rules with their own peculiarity which moves you away from the problem.

You end up solving the framework to work for you than working the problem and let framework fit in place. Its almost ridiculous to keep battling the Rails framework to fit your problem domain.

Occams Razor suggest that simplest answer is also the most probable. The simplest answer is Routing + templating + middleware (RTM) not MVC. Use nodejs, clojure or Sinatra. Anything but rails if you are aiming to go beyond a blog and not want to battle the framework.

Alex Reilly • Oct 16 '18

I see where you're coming from, but I'm an individual contributor working with a small team on an existing project, so I can't exactly waltz into engineering meetings and be like "let's start from scratch using a framework that no one knows" hahah

Pankaj Doharey • Oct 17 '18

Hahah, True! I have commented above in the parent comment section do read it. I explain exactly how rails teams eventually hit a wall.

Sean Walker • Oct 16 '18

You know what, yeah the concepts will come together, stick with it! Rails is still a great framework to learn.

Pankaj Doharey • Oct 16 '18 • Edited

Any moderately complex Rails App is a nightmare to maintain. What havent i seen in the past few yrs of Rails Development.

Starting with Skinny Controllers fat models.. ohh no now the Models are fat!
Well lets use decorators to trim some fat, but wait what about the complex logic that may not fit here? Ahh we have concerns, the only problem is this damn concern has no concern about breaking the MVC!

Few weeks and say, You know what lets extract the business logic and concerns into a external loading library that makes so much sense right?

Few months down the line, hmm i think since we are already using an external library let us "gemify" the library and host it in our internal gemserver. Some features and few weeks later lets gemify all major parts of the Application!

Some more features and few months down the line, lets refactor the s*** out of this code its becoming too complex.

Few more months half a dozen refactoring later, you know what this is getting out of hand lets look for a solution outside of rails ecosystem. After a bit of searching and looking at other rails installs and conf videos.

Aha, just rediscovered SOA (Service oriented architecture) but wait we are hipster rubyists lets not call it with a bigoted evil corporatized name like SOA, it needs a Hippie name, as ascribed by our beloved benevolent dictator DHH.

Lets call it "extraction of business logic" into services! or maybe something simpler like Lambda Architecture?

Well, after some time and few api requests later,

Hmm you see since we have already extracted few of the business logic as gems and then as independent services modeled around lambda architecture (because thats the most hipster thing to do plus i like netflix). Lets rewrite the services in golang or Java or Scala to make it faster. Yippie!!

Meanwhile the other rubyists, meh, i am not going to install JVM on my machine lets look for another VM to install, that can be used to spin our new services.

Suggestion: Well lets use Erlang VM because Whatsapp used it and Dave has written an awesome book on Elixir a new lang on Erlang VM.

Thats your rails app story!

Bruno Nascimento • Oct 24 '18

So what’s your solution/alternative?