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.
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
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.
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.