Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


A Flickr-based Introduction to Ruby on Rails 2.0 : Page 5

Want to get started with Rails 2.0? Explore some of the most prominent new features, and learn how to use them to build a simple, but visually attractive, web application based on Flickr.

Looking at Performance
The user-facing side of RailTrackr is now in place. However, being a resource-intensive application that downloads and processes many photos, performance becomes critical to delivering a smooth experience.

Rails 2.0 contains various improvements to overall performance and supports advanced techniques to speed up the application. Among them, the most interesting ones are:

  • JavaScript bundling
  • Cookie-based sessions
  • Domain multi-targeting
  • Query caching

JavaScript Bundling
JavaScript bundling is the capability to bundle together all the JavaScript files of your application (or part of them) into a single file before sending it to the client. Nowadays, web applications use many JavaScript libraries to provide a better user experience and rich visual effects. The downside is degraded performance because the browser has to perform multiple requests to retrieve every single JavaScript library. By bundling all of them together, Rails 2.0 can speed up the delivery of JavaScript files since the browser needs to perform only one request.

RailTrackr is no different; it requires a lot of JavaScript files to provide its fancy effects. For comparison, Figure 6 shows the time required to access the page that contains all the photosets for a given user without JavaScript bundling and Figure 7 shows how long it takes with JavaScript bundling. Both times are reported by Firebug.

Figure 6. Downloading Lots of JavaScript Libraries Without Bundling.
Figure 7. Time Saved When the Same JavaScript Libraries Are Bundled in a Single File.

Activating JavaScript bundling is dead simple. You need only add the :cache attribute to the javascript_include_tag statement in your view templates, as follows:

<%= javascript_include_tag "prototype" , "effects" , "dragdrop" , "instant" , "reflex" , :cache => "railtrackr" %> <!-- Will create a single railtrackr.js file -->

You can apply the same technique to stylesheet bundling, acting on the stylesheet_include_tag command.

Bundling is enabled when Rails is in production mode and disabled during development, to avoid unnecessary complication to the developer's debugging sessions (and life in general).

Cookie-based Sessions
Another performance improvement results from Rails 2.0 storing session data in browser cookies instead of using the database or temporary files on the server. This places all the state information on the client, allowing the application to behave statelessly—performance can then be improved by horizontal scalability. When necessary, you can add more servers, each one hosting the same exact application, to increase throughput without having to worry about maintaining session data in sync across replicas. However, you should avoid this solution when critical data are stored in session or when session is used to store very big objects, even if Rails uses encryption to store session data in cookies. The reason is the browser sends cookies back to the server for every request (so they have to remain lightweight).

Domain Multi-targeting
Modern browsers usually open only two concurrent connections toward every domain they're accessing. Since the pages of RailTrackr contain lots of images, this may result in a performance impact because of the browser queuing all the requests. With the following statement you can instruct Rails to activate domain multi-targeting and generate URLs for static resources distributed across multiple domains (four by default, whose name is created replacing the %d symbol with the numbers 0 to 3):

ActionController::Base.asset_host = "static%d.yoursite.com"

The browser will then download eight images concurrently instead of two. To activate this change, you have to configure DNS aliases on your domain first.

Query Caching
Lastly, Rails 2.0 contains other performance improvements specific to the database layer, such as query caching, to prevent executing the same query multiple times while processing a single request.

What About the Database?
The sample code is focused only on the changes that Rails 2.0 brought to the user-facing side of application development. It discounts entirely models and database mapping in favor of remote API calls to the Flickr Service. However, the new Rails version contains a whole set of changes to its backend and to the popular ActiveRecord persistence layer. These are beyond the scope of this article, but here are some brief descriptions of the most important changes:

  • Sexy Migrations: The syntax that defines database migrations is now more readable and easier to write.
  • Foxy Fixtures: Test fixtures have been simplified and can reference themselves by name instead of using record IDs as before.
  • ActiveResource: If a remote site exposes some resources through RESTful APIs, you can create a fully working model (with the same functionalities as an ActiveRecord model) by simply extending the ActiveResource class and declaring a site attribute that points to the remote site. As you have seen in this article, Rails 2.0 is fully compatible with REST, so it is trivial to connect remote Rails sites into a single distributed model. (Click here for a screencast that shows the details of ActiveResource).

What Have You Learned?
This article explored the changes Rails 2.0 brought to the web development world. It focused mostly on user-facing aspects, providing full REST support to your application and keeping an eye on performance. It also provided a glimpse at the changes that have occurred to the Rails backend.

Among the smaller features Rails 2.0 introduced are improved debugging thanks to the integration of the ruby-debug library, improved JSON support, improved builders for RSS feeds, namespaced routes, HTTP Basic authentication support, and improved security.

For further exploration of these and other features, check out the links provided in the Related Resources section in the left column, or just play around with RailTrackr and its source code. Remember, updates will be regularly released at battlehorse.net.

Riccardo Govoni has been working since 2003 as a J2EE developer on a variety of applications ranging from financial services to middleware in the IP television field. He currently works for Google as a software engineer. He is a Sun Certified Java Programmer (SCJP).
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date