Rails 4 Targets the Real-Time Web

rails4targetstherealtimewebRuby on Rails remains popular as a highly productive framework for building Web applications. However, it was losing traction to Node.js because of the latter’s ability to handle use cases where data needs to be streamed from server to client (in contrast to the traditional request-response cycle for web applications). The latest release of Rails however, provides some potentially game changing enhancements that open up new application domains to the Rails community. I want to take a look at some of them in this post.

At first look, the move to Rails 4 is not as significant a change as the move to Rails 3 was. Many of the differences with Rails 3 are progressive refinements or maturations of features already present. This has an advantage as it does make the migration of an existing project from Rails 3 to Rails 4 a relatively straightforward process. However, there are three that are key indicators of the way web application development is going, and I feel that together they have an impact that is of major significance to the Rails community. The first of these, and to my mind the most important, is ActionController::Live


This module was developed by Aaron Patterson to enable data to be streamed live from Server to Client. Essentially, instead of returning html or JSON as a response to an html request,  ActionController::Live enables an i/o stream to be returned as a response. This means we can define an action in a controller that will set up a stream of live data to any client that requests it, until the connection is closed again.

Let’s look at a simple example. Suppose we want to remotely monitor some sensors. The following controller will stream 100 temperature values to a client in response to a request to: http://www.myMachine.com/sensor/temperature.

class SensorController < ApplicationController

 include ActionController::Live

 def temperature

   response.headers[‘Content-Type’] = ‘text/event-stream’

   100.times {

     response.stream.write(“The temperature is #{ 100*rand} degrees Celcius\n”)

     sleep 0.5


   response.stream.write(“That’s all for now!”)





This is not quite where we want to be as the data is just streamed in an unstructured way into a browser. However, thanks to HTML5’s Server-Sent Events (SSE), we can wrap our data into an SSE before streaming it and then arrange for the appropriate element in an HTML document to be updated every time a data update event is received.

As I said, this really is a game changer for Rails. It opens up a new suite of use cases where we can implement live chat, real-time data feeds (as illustrated here) and push notifications without having to move outside Rails.


Although an apparently small change, Turbolinks is symptomatic of the direction that Web application development is moving. CSS3 continues to develop, and the performance of CSS and JavaScript interpreters continues to improve in browsers. As a result, we are steadily seeing increasing use of CSS and JavaScript to enhance the user experience of web applications. The downside of this is that a significant amount of processing needs to take place on the client side on every page change. The idea behind Turbolinks is to try and treat a web site as a single page, and only change the title in the Head and its body as the user navigates around the site. This means that the JavaScript and CSS files that are referenced in the head do not need to be recompiled when a page is changed.

The bottom line is that this can lead to very significant performance enhancements if your application uses a lot of CSS and/or JavaScript. Whilst Turbolinks could be used in Rails 3, it is enabled by default in Rails 4. There are some gotchas to watch out for, but these can be easily resolved. The general lesson is a simple one, however. Whether we program it ourselves (with Ajax) or rely on tools in the framework we are using (with Turbolinks, for example), we will get the best user experience if we ensure that there is always minimal change as the user navigates through a Web application.

Russian Doll Caching

ActionView in Rails has some tremendous productivity and maintenance advantages, with its combination of layouts, views and partials to eliminate duplication of content. However, the downside of this is that the rendering process is complex and, hence, slow. Russian Doll caching is a significant step on the way to fixing this issue, with some tests reporting a 67% reduction in load time per page.

The idea here is that fragments of a page can be cached. Then, if the caching of one fragment auto-expires (due to its content being updated) the cache of the parent will also expire. However, all the other nested fragments can be reused (the Russian Dolls). As with Turbolinks, this is not an enhancement to functionality but it is a significant enhancement to the usability and responsiveness of Rails applications.

What next?

For the last two years, I have found myself being pulled in two directions: Rails for “mainstream applications”; Server-side JavaScript for real-time web applications. Now with Rails 4, I can once again start to innovate within just the one framework.

If you are new to Rails and want to learn more, fear not. Getting Started with Ruby on Rails does what it says, but also leads you through to an understanding of these Rails 4 features. Check-out this on-demand online course at a 50% discount.

About the Author:

paul_krausePaul Krause teaches ‘Getting Started with Ruby on Rails‘ for Udemy. He has over twenty-five years of experience in the research and development of complex software systems. His work has been used in the development of a wide range of products for the medical systems, consumer electronics, information systems, and more recently, web applications domains. He is especially interested in using the Web to enhance people’s engagement with the natural world, as reflected in his work with Tiger Nation and with his local Wildlife Trust.