Real-Time Apps With WebSockets and Action Cable

Learn to build real-time apps with Ruby on Rails

Oct 1, 2020 • posted by Michael Hartl

Learning to code? Learn Enough is based on the idea that you don’t have to learn everything about tech to get started—you just have to learn enough to be dangerous. This is the ninth and final post in a series introducing the main Learn Enough tutorials. You can also read the previous ones.

Michael Hartl here from the Rails Tutorial and Learn Enough.

People often ask me what their next step should be after finishing the Ruby on Rails Tutorial. The short answer is that there are a huge number of possible subjects to learn next, but an especially useful one is learning how to make real-time apps using a technology called WebSockets. Perhaps the best example of this is chat apps, where any messages you send immediately show up in other users’ browsers without the need to refresh the page, but the applications are endless.

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

Action Cable overview

Learn Enough Action Cable to Be Dangerous consists of five short chapters focused on getting you up and running with real-time apps as quickly as possible. Chapter 1 starts with a brief overview of Action Cable, including a discussion of what WebSockets are and what they can do. Section 1.2 introduces the base application, which is a pre-existing Rails chat app made using the standard REST architecture. Chapter 2, covers some aspects of JavaScript and related technologies needed to build real-time apps. Then Chapter 3 upgrades the application to use Action Cable. Chapter 4 adds some basic enhancements, with more advanced enhancements added in Chapter 5, and then Section 5.3 shows how to deploy the application to production.

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)2 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).3 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”).4

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)5 and Bob (Figure 5)6 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.

How to get it

There are multiple ways to get Learn Enough Action Cable to Be Dangerous. All the different formats cover the same basic material in slightly different ways.

2. Figures adapted with permission from the article “Real-Time Rails” on the Heroku blog.
3. Image retrieved 2016-10-24 from and is in the public domain.
4. 301 (usually pronounced “three oh one”) is sometimes used as a verb, as in “Please don’t break your old links; 301 them to the new pages instead.”
5. Alice’s Adventures in Wonderland original illustrations by John Tenniel. Image retrieved from on 2019-02-15. Copyright © 1890, now in the public domain.
6. Image retrieved from 2019-02-15. Copyright © 1912 by Jessie Wilcox Smith, now in the public domain.
learnenough-news , tutorials , action-cable , websockets , rails