Rails 5.2 Beta is almost upon us, and I would bet that most of the Rails projects out there are in the 4.2 version, still thinking about doing the jump to 5.0 (which is not so bad an upgrade).

By the way, in case you didn’t know, the official Rails Guides website has a section dedicated to upgrades. It’s called A Guide for Upgrading Ruby on Rails. The process of upgrading is not actually so difficult if, and only if:

• You have a fairly good test coverage. You should have, at the very least, feature specs for the most important parts of your system.

• You should upgrade to just one subsequent version at a time, never going straight to the most recent one. For example, If you’re in Rails 4.1, you must first upgrade to 4.2, make sure everything works. Then go to 5.0. And only then go to 5.1. Each version has many deprecations, changes in behavior, changes in default boilerplate configuration, added new features. You must attend to each very carefully.

So, what are you missing if you’re still in Rails 4.2?

Again, in case you didn’t know, the official Rails Guides website also compiles detailed and easy to read Release Notes for each new version. The most recent are the Ruby on Rails 5.1 Release Notes.

Starting a new project

The rails new command has a lot of new flags. And I think these are the ones most people will use:

rails new --skip-action-mailer --skip-coffee --webpack=react my_fancy_new_project

You can disable features you don’t need such as ActionMailer or ActionCable. You can disable CoffeeScript. It was cool for a while but now that ES6 exists we should just use it.

Rails 5.1 comes with the support for webpack. But until Rails 5.2 comes up, we need to use the webpack-dev-server manually in development mode so we can hot reload assets. For that end, I recommend installing good old Foreman. Install it like this:

gem install foreman

And add a Procfile.dev file to your project with the following content:

web: ./bin/rails s -b 0.0.0.0 -p 3000
webpack: ./bin/webpack-dev-server

And now you can start up your development server like this:

foreman start -f Procfile.dev

In production, you don’t need the webpack-dev-server as the bin/rails assets:precompile task should be able to compile all the assets you need as static, timestamped files in public/assets.

Front-end Specific Changes

Now, you can rejoice with Yarn, Webpack, and no more jQuery pre-installed. Samuel Muller has a nice article that summarizes most of these changes in more detail.

Now Ruby on Rails officially supports every bell and whistle from the Javascript ecosystem. There is nothing left behind that you might miss.

No more manually vendoring JS assets in vendor/assets/javascripts directory. No more need to use Rails Assets, which was a secondary RubyGems source specific to package JS libraries into RubyGems.

Let’s say that, for some reason, you want jQuery back. You can now just do:

yarn add jquery

And, as usual, you can simply add it to your app/assets/javascripts/application.js manifest file:

// app/assets/javascripts/application.js
...
//= require jquery
...
//= require_tree .

The so-called “support for Yarn in Rails 5.1” boils down to a few wrappers and boilerplate. So you can run rails yarn:install and have the dependencies installed, but you can just as easily type yarn and it will install everything you need that is declared in the package.json file, as with any other Javascript-only project.

Now, the whole magic of the integration comes from the inclusion of the Webpacker gem. It adds a bunch of boilerplate configuration for webpack. And, bonus fact you can include it today in your current Rails 4.2+ projects as well. Just start by adding the webpacker gem to your Gemfile:

# Gemfile
gem 'webpacker', '~> 3.0'

Then bundle install as usual and run:

bundle exec rake webpacker:install

If you didn’t use the --webpack=react flag to the rails new command, you can add it later. Or you can add Angular as well:

bundle exec rake webpacker:install:angular
bundle exec rake webpacker:install:react 

You should replace bundle exec rake for bin/rails if you’re in Rails 5.1.

Adding proper React components is a bit more than the command above though. And the details are more than I want to cover in this post.

Andy Barnov has a good post on how to follow the Rails 5.1 packs convention to add your React components in the pipeline. As he recommends, don’t fight the conventions and you should be golden.

Oddly enough, even though I used the --webpack-react flag to the rails new I still had to run the following command to bootstrap the webpack and react supports:

./bin/rails webpacker:install:react

But once you do, you will get a new place to add React components, and that’s in a proper app/javascripts/packs. And in the views, instead of the usual javascript_include_tag you will use the brand new javascript_pack_tag. I believe you can figure out the rest from the example component hello_react.jsx that it generates for you.

Final Thoughts

You now have a whole lot more options for Javascript, as Rails 5.1 fully embraces the current standards.

Once upon a time, no one properly knew how to streamline an Asset Pipeline. It was very messy to compile all your assets in a single file with proper cache busting timestamps, but the Sprockets gem did it.

Once upon a time, Javascript 5 was a damn mess. Libraries such as jQuery actually “fixed” most of the browser DOM situation, and CoffeeScript normalized the language in a way that made it enjoyable. ES6 came to take over the reins but it’s very unfair to criticize jQuery and Coffee as neither ES6 nor HTML5 were there to solve the situation almost 10 years ago. jQuery and Coffee were there, and they solved it.

When Angular, Ember, and React were starting, we already had a good enough solution for javascript-heavy websites with Turbolinks. This is still a very good solution that you should consider using instead of adding a full-blown (and sometimes unnecessary) React/Redux solution at once.

CSS is another matter entirely. The Rails community also created Sass (which then Twitter envied and copied to Less for the Bootstrap framework).

It’s easy to see the current landscape and just repeat that Coffee is bad or Sprockets is bad. But for the past 10 years, those tools were the best of breed in a time where people didn’t have Yarn, Webpack, React and all the tools that popped up in the past 3 years or so.

Rails 5.1 is a very good release to marry the best of Rails with the best that kinda stabilized today in the Javascript mad arena. And I highly recommend that any new, greenfield project, start with Rails 5.1 in mind.

One thing that led me to write this post is to highlight that many people ask questions that are mostly answered in the official Rails Guides. Not only on how to install and use the many components of the framework but also how to upgrade and what the new features of each release are. So you should definitely take a better look there.

Comparisons are always unfair. There is no such thing as a “fair” synthetic benchmark comparison, the author is always biased towards some targeted result. It’s the old pseudo-science case of having a conclusion and picking and choosing data that backs those conclusions. There are just too many different variables. People think it’s fair when you run it in the same machine against 2 “similar” kinds of applications, but it is not. Please don’t trust me on this as well, do your own tests.

All that being said, let’s have some fun, shall we?

The Obligatory “Hello World” warm-up

For this very short post, I just created a Node.js + Express “hello world,” I will point to its root endpoint, Express, rendering a super simple HTML template with one title and one paragraph.

For Elixir, I just bootstrapped a bare-bone Phoenix project and added one extra endpoint called “/teste” in the Router. This endpoint will call the PageController, then the “teste” function, and render an EEX template with the same title and paragraph as in the Express example.

Simple enough. Phoenix does more than Express, but this is not supposed to be a fair trial anyway. I chose Siege as the testing tool for no particular reason. You can pick the testing tool you like the most. I am running this over my 2013 Macbook Pro with 8 cores and 16GB of RAM, so this benchmark will never max out my machine.

The first test is a simple run of 200 concurrent connections (the number of CPUs I have) firing just 8 requests each for 1,600. First, the Node.js + Express results:

The first run already broke a few connections, but the 2nd run picked up and finished all 1,600 requests. And this is the Phoenix results:

As you can see, Node.js has the upper hand in terms of the total time spent. One single Node.js process can only run one single real OS thread. Therefore it had to use just a single CPU core (although I had 7 other cores to spare). On the other hand, Elixir can reach all 8 cores of my machine, each running a Scheduler in a single real OS thread. So, if this test was CPU bound, it should have run 8 times faster than the Node.js version. As the test is largely a case of I/O bound operations, the clever async construction of Node.js does the job just fine.

This is not an impressive test by any stretch of the imagination. But we’re just warming up.

Oh, and by the way, notice how Phoenix logs show the request processing times in MICROseconds instead of milliseconds!

The Real Fun

Now comes the real fun. In this second run, I added a blocking “sleep” call to both projects, so each request will sleep for one full second, and this is not absurd. Many programmers will use poor code that blocks for that time, process too much data from the database, render templates that are too complex, and so on. Never trust a programmer to follow best practices all the time.

Then, I fire up Siege with ten concurrent connections and just one request each, for starters.

This is why in my previous article “Why Elixir?” (http://www.akitaonrails.com/en/2015/12/01/o-obrigatorio-por-que-elixir-visao-pessoal), I repeated many times how “rudimentary” a Reactor pattern-based solution is. It is super easy to block a single-threaded event loop.

If you didn’t know that already, how does Node.js work? In summary, it is a simple infinite loop. When a Javascript function runs, it blocks that event loop. The function has to explicitly yield control back to the loop for another function to have a chance to run. I/O calls take time and just sit back idly waiting for a response, so it can yield control back and wait for a callback to continue running, which is why you end up with the dreaded “callback pyramid hell”.

Now, with what I explained in all my previous articles, you may already know how Elixir + Phoenix will perform:

As expected, this is a walk in the park for Phoenix. It doesn’t have a rudimentary single-thread loop waiting for the running functions to yield control back willingly. The Schedulers can forcefully suspend running coroutines/processes if they think they are taking too much time (the 2,000 reductions count and priority configurations), so every running process has a fair share of resources to run.

Because of that, I can keep increasing the number of requests and concurrent connections, and it’s still fast.

In Node.js, if a function takes 1 second to run, it blocks the loop. When it finally returns, the next 1-second function can run. That’s why if I have ten requests taking 1 second each to run, the entire process will linearly take 10 seconds!

Which obviously does not scale! If you “do it right,” you can scale. But why bother?

“Node” done right

As a side note, I find it ironic that “Node” is called “Node.” I would assume that connecting multiple Nodes that communicate with each other should be easy. And as a matter of fact, it is not.

If I had spun up 5 Node processes, instead of 10 seconds, everything would take 2 seconds as five requests would block the 5 Node processes for 1 second, and when returned, the next five requests would block again. This is similar to what we need to do with Ruby or Python, which have the dreaded big Global Interpreter Locks (GIL) that, in reality, can only run one blocking computation at a time. (Ruby with Eventmachine and Python with Tornado or Twisted are similar to Node.js implementation of a reactor event loop).

Elixir can do much better in terms of actually coordinating different nodes, and it is the Erlang underpinnings that allow highly distributed systems such as ejabberd or RabbitMQ to do their thing as efficiently as they can.

Check out how simple it is for one Elixir Node to notice the presence of other Elixir nodes and make them send and receive messages between each other:

Yep, it is this simple. We have been using Remote Procedure Calls (RPC) for decades; this is not new. Erlang has implemented this for years, and it is built-in and available for easy usage out-of-the-box.

On their websites, ejabberd calls itself a “Robust, Scalable, and Extensible XMPP Server,” and RabbitMQ calls itself “Robust messaging for applications.” Now we know they deserve the labels “Robust” and “Scalable.”

So, we are struggling to do things that have been polished and ready for years. Elixir is the key to unlocking all this Erlang goodness right now. Let’s just use it and stop shrugging.