Example of a Real-Time, Asynchronous Web Application

steps1 2

There’s been a lot of buzz about the “real-time” web among developers lately. As browsers and frameworks mature, it’s becoming increasingly advantageous to build fully asynchronous websites. But what is the real-time web? The answer may vary depending on who you ask, but the one common thread is that real-time websites enable the client (web browsers) to react instantly to changes on the server. Real-time web apps allow performance that rivals native apps, avoiding most of the delay intrinsic to traditional client-server systems (in which browsers only get new content by requesting it from servers). This post is intended to give an overview of the architectural decisions for an asynchronous web application — our newest product, WhitePages Mailer.

Screen shot 2012 12 12 at 10.12.00 AM


The core ingredients:

  • Ruby on Rails — our server-side framework.
  • Spine.js — our client-side framework.
  • Sidekiq — for asynchronous processing.
  • Faye — pub/sub messaging, connecting client to server via websockets.

Ruby on Rails

Ruby on Rails is a server-side MVC framework that provides database, templating, session, and asset management.  We primarily use Ruby on Rails as a JSON API, and for serving assets.  Rails has an “Asset Pipeline” that’s responsible for compressing and serving JavaScript.  We have a lot of JavaScript, so much that we have another MVC framework to offer some abstraction: Spine.js.


Spine.js is a client-side MVC framework designed to provide abstraction for asynchronous, responsive user interfaces.  To ensure asynchronicity and responsiveness, all view rendering is done client-side, which means we don’t really use the Ruby on Rails template management: we use Spine’s client-side JavaScript templates.  (It’s actually CoffeeScript but let’s ignore implementation details for now).  Spine gets some of its data from AJAX calls to the JSON API on the Rails server, and some of its data from background processes that run on Sidekiq servers.

steps1 2


Sidekiq is a server-side message processor.  Ruby on Rails (like Django) assumes synchronous programming.  Without Sidekiq to process background jobs asynchronously, any long-running processes (such as importing all of a user’s friends from Facebook) would block Rails. With Sidekiq, when any client requests a long-running job, it’s handed off to Sidekiq (via Redis), which processes the job and then then publishes the result to the client via a websocket.

steps3 4



Faye is a publish-subscribe messaging system responsible for transporting the messages between servers and clients.  There’s a server-side, Ruby component of Faye that publishes messages (by broadcasting to an established channel), and a client-side, JavaScript component of Faye that subscribes to that channel and receives the messages.  By using websockets we’re able to push data from the server to the client whenever it’s ready, instead of waiting for the client to request it (e.g. polling).

With this architecture, page transitions can be instantaneous, and the UI can react in real-time to server activity (such as updating the progress bars in import and export jobs, and rendering each contact as they’re imported).  Check it out at WhitePages Mailer and let us know what you think.



Find Jared on Google +

by Whitepages

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>