Hartl - Learn Enough Action Cable to Be Dangerous

The WebSocket Protocol is a complement to the standard HyperText Transfer Protocol (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 requestresponse cycle (

Figure 1: The requestresponse cycle of the HyperText Transfer Protocol.

Figure 2: An early walkie-talkie.

In contrast to HTTPs half-duplex communication, the WebSocket Protocol allows full-duplex communication between client and server (after an intial one-way request using a . This connection allows the client and server to communicate simultaneously and persistentlyi.e., instead of a walkie-talkie, we have a mobile phone.

Figure 3: The WebSocket procotols full-duplex communication.

For example, consider a chat app written using HTTP. Alice (). When Alice submits a message, theres 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 its inefficient because the polling happens regardless of whether theres 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. Its 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 its not too hard.

Making WebSockets not too hard is the purpose of Action Cable.

Figure 4: Alice.

Figure 5: Bob.

Figure 6: A chat box.

The reason using WebSockets is better than polling is because there is a bi-directional connection between the server and each client, so Alices submitted message gets pushed to Bob immediately after being received by the server. Moreover, because the connection is persistent, Alice and Bob can submit their messages at the same time and still see their respective messages appear immediately. Finally, the WebSocket protocol scales much better with multiple users, with the server simply maintaining one WebSocket per client, updating only as necessary.

When using WebSockets, its nice to be able to have users log in, store their attributes in a database, render templates back to the browser, etc. In other words, its nice to have the full power of Ruby on Rails behind us. This is where Action Cable comes in. Using Action Cable gives us the best of both worlds: real-time, full-duplex communications with WebSockets combined with all the convenience and flexibility of Rails.

To show off power of WebSockets, the rest of this tutorial develops a simple real-time chat app with Action Cable. The final design combines aspects of Rails 5: Action Cable Demo by DHH and Real-Time Rails by Sophie DeBenedetto. In particular, although well be using some of the more advanced techniques introduced by DHH, well be sure to ground our app in the kind of standard REST design used for non-WebSocket apps.

Well start by giving a high-level overview of the base app ().

Well begin with a base app that implements the basic functionality of a chat app but without Action Cable (or even polling). The purpose is to start with an app design that is familiar from other REST-style applications, thus helping to bridge the gap to the Action Cable style used starting in .

The base app works as a chat app, but its intentionally impractical. In particular, chat participants have to manually refresh their browsers to see messages from other users. This cumbersome design provides ample motivation to implement an Action Cable solution. (The base app also has no mechanism for letting new users register for the site, but such straightforward extensions should be within your capabilities if youre reading this tutorial, or can be found in the Ruby on Rails Tutorial.)

Rather than build the base app from scratch, well instead fork and clone the app from a reference repository, and then go over its most important parts.

The base apps source is hosted at .

Figure 7: Forking the chat app repo.

Figure 8: Getting the chat app clone URL.

Once youve forked the repo, you should grab the clone URL () and then clone it at the command line as follows:

$ git clone https://github.com//action_cable_chat_app.git

Then cd into it as follows:

$ cd action_cable_chat_app/

Then install any necessary gems and prepare the database and seed data:

$ bundle install $ rails db:migrate $ rails db:seed

Finally, run the test suite to make sure the app is working:

$ rails test

If the tests fail, use your technical sophistication () to debug the issue.

Box 1. Technical sophistication.

One of the principal themes developed by Learn Enough to Be Dangerous is technical sophistication, the knowledge and attitude needed to solve technical problems. Its likely that you will have ample opportunity to exercise your technical sophistication when following