loading...

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]
markdown guide
 

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.

 

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!

 

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

 

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)
 

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.

 

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

 

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

 

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.

 

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

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

 

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

 

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!

 
 

That was a real pleasure to read this, great, thanks!

code of conduct - report abuse