Rails Action Cable — A Simpler Perspective
I’m an aspiring Software Engineer who, admittedly, joined the game a little late during my university career. As (I’m sure) many can relate, learning what some of these complex systems are and how they work involves lots of documents, time and confusion. I went through this, and to hopefully save some of you some time I consolidated my learnings.
Disclaimer: I have to credit Christopher Sexton’s presentation on the topic available here: https://www.youtube.com/watch?v=XeqLONJsHkY. I would strongly recommend giving this video a watch!
What is Rails Action Cable?
Rails Action Cable is a rails solution to performing background tasks using a Redis Server. For example, think of a typical synchronous application as a restaurant with a single employee acting as both the waiter and the chef. To ensure the food doesn’t burn, the employee must get the order, prepare it, then return it to the customer before he/she can move on to the next table. Customers are left waiting at their table for their food to “load”, but what if after they order they realize they need a glass of water? What should be a simple task now has to wait for the longer task to complete before it can be performed.
Introducing Action Cable to an application would be similar to adding a new employee to this restaurant who’s job is solely to be the cook in this scenario. The waiter should not be blocked from taking new orders and checking in on customers when the food is being prepared! Now the waiter (main application) can get the order to the cook (Action Cable Server) and forget about it until it’s finished.
Why use it?
First off, Action Cable has server to client push, which would be similar to the cook having a bell to ring when the food is ready, rather than having the waiter ask every 5 minutes if it’s ready. Now the entirety of the waiter’s attention can be spent on pleasing the customer. Also, with traditional synchronous rest calls 80% of the bandwidth can be attributed to headers for authorization and authentication for what is only a 20% payload. From an efficiency perspective this is far less than ideal if you have to make numerous cascading calls to your server. With Rails Action Cable and WebSockets this overhead can be drastically reduced!
Lifecycle
Client Connects To Cable
The client will send a normal looking HTTP request to the server with all auth headers attached. This is really no different from a normal call, except that it’s looking to connect to what is called a cable. A cable is a generic abstraction of handling the passing of information back and forth, and is facilitated over a WebSocket. Most of this is done when the server handles the connection (see below).
Server Handles Connection
The server processes the headers, checks the auth credentials and validates the payload. It then creates a handshake connection called a WebSocket from the HTTP request using Rack Hijack. This allows for continuous two-way data transfer without needing to authenticate every time information is passed. Relating back to the restaurant example, imaging that every time the waiter needed to interact with the chef he/she needed to recite a (long) passcode which the chef then has to double check against a handmade list of hundreds of employees, would probably slow things down right? No think of how they actually work, the waiter and chef see each other in the morning, then throughout the rest of the day they do their jobs without needing to re-establish their identity.
Clients Subscribes to Channel
Action Cable allows for a pub/sub architecture to various channels. Channel streams are abstractions used to specify types of data being passed. Relating this back to the restaurant, the notification channel would be equivalent to the waiter actively listening for the bell the chef rings when the food is ready. When the waiter is on break he stops listening to (unsubscribes from) the bell until he’s done.
Client sends messages to the server & Server Responds to Client
This is the information transfer between client and server until the connection is terminated.
Conclusion
Smaller applications can get away with having a single stream of information and multiple HTTP requests. However, upon scale you might need to consider the implementation of other systems to help with things like background jobs. Rails Action Cable bridges that gap by leveraging (if you choose) a speedy Redis server, alleviating some load on your core application. Action Cable is great for things like sending emails in the background, processing your CRON jobs or doing some data cleanup.
