Common Ruby on Rails Issues and Takeaways

Welcome to the final a part of my Ruby on Rails Patterns and Anti-Patterns collection. It’s been fairly a journey writing and researching all of those subjects. On this weblog submit, we’ll go over the commonest issues I’ve encountered when constructing and transport Ruby on Rails functions by means of the years.

The concepts I’ll undergo right here apply to nearly wherever within the code. So contemplate them as normal concepts, not one thing associated to the Mannequin-View-Controller sample. In case you are fascinated with patterns and anti-patterns associated to the Rails MVC, you’ll be able to try the Mannequin, View, and Controller weblog posts.

So let’s soar into normal issues and takeaways.

Egocentric Objects (Regulation of Demeter)

The Regulation of Demeter is a heuristic that acquired its identify when a bunch of individuals labored on the Demeter Mission. The thought is that your objects are effective so long as they name one technique at a time and don’t chain a number of technique calls. What this implies in observe is the next:

music.label.handle


music.label_address

So now, the music object now not must know the place the handle comes from — the handle is the accountability of the label object. You’re inspired to chain just one technique name and make your objects ‘egocentric’ in order that they don’t share their full data straight however by means of helper strategies.

def Music < ApplicationModel
  belongs_to :label

  delegate :handle, to: :label
finish

You may go forward and mess around with the choices that delegate accepts in delegete’s docs. However the thought and execution are fairly easy. By making use of the Regulation of Demeter, you scale back structural coupling. Along with the highly effective delegate, you do it in fewer strains and with nice choices included.

One other concept that’s similar to the Regulation of Demeter is the Single Duty Precept (or SRP for brief). It states {that a} module, class, or operate ought to be accountable for a single a part of a system. Or, introduced in one other means:

Collect collectively the issues that change for a similar causes. Separate these issues that change for various causes.

Of us can usually have a unique understanding of SRP, however the thought is to maintain your constructing blocks accountable for a single factor. It may be difficult to realize SRP as your Rails app expands, however concentrate on it when refactoring.

When including options and growing the LOC, I’ve discovered that folk usually attain out for a fast resolution. So let’s undergo grabbing the short repair.

I Know a Man (Do You Want That Ruby Gem?)

Again within the day when Rails was a sizzling subject, there was a growth in open-source collaboration, with new Ruby gems popping up on each nook (like it’s these days with all of the rising JavaScript libraries, however on a a lot smaller scale):

Anyway, a standard strategy was to search out an present gem to unravel your downside.

There’s nothing improper with that, however I’d wish to share some bits of recommendation earlier than you resolve to put in a gem.

First, ask your self these questions:

• What portion of the gem’s options are you going to make use of?
• Is there an analogous gem on the market that’s ‘less complicated’ or extra up-to-date?
• Are you able to implement the function you want simply and with confidence?

Consider whether or not it’s price doing the implementation for those who don’t plan to make use of the entire array of gem options. Or, if the gem’s implementation is simply too complicated and also you imagine you are able to do it extra merely, go for a customized resolution.

One other issue that I contemplate is how energetic the gem’s repository is — are there any energetic maintainers? When was the final time a launch occurred?

One other factor to be careful for is the gem’s dependencies. You don’t need to get locked into a selected model of a dependency, so at all times verify the Gemfile.spec file. For this case, at all times seek the advice of the .

You must also be careful for the gem’s dependencies. You don’t need to get locked into a selected model of a dependency, so at all times verify the Gemfile.spec file. Seek the advice of the RubyGems means of specifying gem variations.

Whereas we’re on the subject of gems, there’s a associated concept that I’ve encountered: the ‘Not Invented Right here’ (or NIH) phenomenon that applies to the Rails/Ruby world. Let’s see what it’s about within the subsequent part.

Not Invented Right here (Possibly You Want That Ruby Gem after All?)

In a few occurrences in my profession, I had an opportunity to expertise folks (me included) fall for ‘Not Invented Right here’ syndrome. The thought is much like ‘reinventing the wheel’. Generally, groups and organizations don’t belief libraries (gems) that they will’t management. Lack of belief may be a set off for them to reinvent a gem that’s already on the market.

Generally, experiencing NIH could be a good factor. Making an in-house resolution will be nice, particularly for those who enhance it over the opposite options on the market. When you resolve to open-source the answer, that may be even higher (check out Ruby on Rails or React). However if you wish to reinvent the wheel for the sake of it, don’t do it. The wheel itself is fairly nice already.

This subject is kind of tough, and for those who ever get caught in such a state of affairs, ask your self these questions:

• Are we assured that we are able to make a greater resolution than present ones?
• If the prevailing open-source resolution differs from what we want, can we make an open-source contribution and enhance it?
• Moreover, can we change into the maintainers of the open-source resolution and presumably enhance plenty of builders’ lives?

However generally, you simply need to go your personal means and create a library your self. Possibly your group doesn’t like licensing an open-source library, so you might be pressured to construct your personal. However no matter you do, I’d say keep away from reinventing the wheel.

Lifeguard on Obligation (Over-rescuing Exceptions)

Folks are likely to rescue extra exceptions than they initially aimed for.

This subject is a little more associated to the code than the earlier ones. It may be widespread sense to some, however it may be seen within the code infrequently. For instance:

start
  music.upload_lyrics
rescue
  places 'Lyrics add failed'
finish

If we don’t specify the exception we need to rescue, we’ll catch some exceptions that we didn’t plan to.

On this case, the issue may be that the music object is nil. When that exception will get reported to the error tracker, you may suppose that one thing is off with the add course of, whereas really, you may be experiencing one thing completely completely different.

So, to be secure, when rescuing exceptions, be sure to get a listing of all of the exceptions that may happen. When you can’t receive each exception for some motive, it’s higher to under-rescue than to over-rescue. Rescue the exceptions that and deal with the others at a later stage.

You Ask Too A lot (Too Many SQL Queries)

On this part, we’re going to undergo one other net improvement, relation-database downside.

You bomb the webserver with too many SQL queries in a single request. How does that downside come up? Nicely, it may well occur for those who attempt to fetch a number of data from a number of tables in a single request. However what most frequently occurs is the notorious N+1 question downside.

Think about the next fashions:

class Music < ApplicationRecord
  belongs_to :artist
finish

class Artist < ApplicationRecord
  has_many :songs
finish

If we need to present a few songs in a style and their artists:

songs = Music.the place(style: style).restrict(10)

songs.every do |music|
  places "#{music.title} by #{music.artist.identify}"
finish

This piece of code will set off one SQL question to get ten songs. After that, one further SQL question will probably be carried out to fetch the artist for every music. That’s eleven (11) queries complete.

Think about the state of affairs if we load extra songs — we’ll put the database beneath a heavier load making an attempt to get all of the artists.

Alternatively, use consists of from Rails:

songs = Music.consists of(:artists).the place(style: style).restrict(10)

songs.every do |music|
  places "#{music.title} by #{music.artist.identify}"
finish

After the consists of, we now solely get two SQL queries, irrespective of what number of songs we resolve to indicate. How neat.

A method you’ll be able to diagnose too many SQL queries is in improvement. When you see a bunch of comparable SQL queries fetching knowledge from the identical desk, then one thing fishy is happening there. That’s why I strongly encourage you to activate SQL logging on your improvement surroundings. Additionally, Rails helps verbose question logs that present the place a question known as from within the code.

If logs shouldn’t be your factor, otherwise you need one thing extra critical, check out AppSignal’s efficiency measuring and N+1 question detection. There, you’re going to get a superb indicator of whether or not your subject comes from an N+1 question. Right here’s the way it seems to be beneath:

Sum Up

Thanks for studying this weblog submit collection. I’m glad you joined me for this fascinating journey, the place we went from introducing patterns and anti-patterns in Rails to exploring what they’re contained in the Rails MVC sample, earlier than this last weblog submit on normal issues.

I hope you realized so much, or at the very least revised and established what you already know. Don’t stress about memorizing all of it. You may at all times seek the advice of the collection if you’re having bother in any space.

You’ll absolutely encounter each patterns and anti-patterns as a result of this world (and software program engineering particularly) shouldn’t be ultimate. That shouldn’t fear you both.

Mastering patterns and anti-patterns will make you an incredible software program engineer. However what makes you even higher is understanding when to interrupt these patterns and molds, as a result of there is no such thing as a good resolution.

Thanks once more for becoming a member of and studying. See you within the subsequent one — and cheers!