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:
- Cookie-based sessions
- Domain multi-targeting
- Query caching
"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).
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 statelesslyperformance 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).
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.
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.