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. You might also enjoy the Learn Enough Action Cable free sample chapter and free sample videos.
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.
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
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.
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.
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.
- The Learn Enough Action Cable to Be Dangerous online course subscription or ebook (including three free sample chapters).