Real-Time Apps With WebSockets and Action Cable

Rails and Action Cable

Learn Enough Action Cable to Be Dangerous is an introduction to Action Cable, a WebSockets interface for Rails that combines ultra-responsive real-time applications with the power and convenience of Rails. Its main prerequisites are a knowledge of Rails at the level of the Ruby on Rails Tutorial and technical sophistication at the level of Learn Enough Git to Be Dangerous. A working knowledge of JavaScript is also recommended, but is not strictly necessary.¹

Web sockets

So, what exactly are WebSockets? Briefly, they’re a way to get around some of the restrictions of the HyperText Transfer Protocol (HTTP) used by default on the Web. In particular, the WebSocket Protocol is a complement to standard HTTP that creates a persistent connection between servers and clients, allowing two-way communication between them. The result is that WebSockets allow developers to create real-time applications such as chat apps and game servers that are far more interactive than ordinary web pages.

In HTTP, the standard request–response cycle (Figure 1)² allows for a huge variety of apps—including nearly all of the apps currently in existence—but it isn’t well-suited to real-time apps that require the server and client to be in constant communication. HTTP’s design is what’s known as “half-duplex”, which means that only one half of the client/server system can be “talking” at a given time. This design is simple and efficient, and shows up in situations such as CB radios and walkie-talkies (Figure 2).³ When using such devices, users are restricted to a single communication band, requiring the use of a standard word or phrase to indicate the end of a one-way message (such as “Over”) to let the other person know they can begin talking. In the context of HTTP responses, these messages take the form of standard status codes, such as 200 OK and 301 Moved Permanently (known colloquially as a “301 redirect”).⁴

Figure 1: The request–response cycle of the HyperText Transfer Protocol.

Figure 2: An early walkie-talkie.

In contrast to HTTP’s half-duplex communication, the WebSocket Protocol allows full-duplex communication between client and server (after an intial one-way request using a header called “Upgrade”), as shown in Figure 3. This connection allows the client and server to communicate simultaneously and persistently—i.e., instead of a walkie-talkie, we have a mobile phone.

Figure 3: The WebSocket procotol’s full-duplex communication.

For example, consider a chat app written using HTTP. Alice (Figure 4)⁵ and Bob (Figure 5)⁶ each type in their respective chat boxes (Figure 6). When Alice submits a message, there’s no way for Bob to get it without refreshing his browser. As a result, the traditional solution for HTTP chat is to use polling, whereby the client runs a program (typically in JavaScript) to pull in any changes every few seconds.

Polling is sufficient in situations where a short delay is acceptable, but it’s inefficient because the polling happens regardless of whether there’s a new message or not, and it scales horribly as clients are added, because each client has to hit the server every time it polls. It’s not a disaster, and the chat app for Basecamp (the original Rails app) used polling for years. But, as Rails creator David Heinemeier Hansson (DHH) has noted, using WebSockets is even better, as long as it’s not too hard.

Making WebSockets easy (or at least not too hard) is the purpose of Action Cable.

Figure 4: Alice.

Figure 5: Bob.

Figure 6: A chat box.