Websocket and ActionCable: A Blog Entry

Here’s a blog entry! It’s about utilizing WebSocket and ActionCable for front-end and backend communication. Neat! What are they? How do they work? Let’s learn!


Or if you were into my food analogy, here are some gifs for reference

HTTP: Individual requests one after another
WebSocket: One always open connection

The only problem with WebSocket is that there is no easy way to have it talk to your front end. Enter Action Cable!

Action Cable

CONNECTION: A connection is exactly what it sounds like. It’s a user being connected to your server. A single Action Cable server can have many connection instances

CONSUMER: So this is just a user. I don’t know why Action Cable gave it such a dark name, but here you go. We don’t call them users anymore because they are sheep and must be called consumers henceforth. (Actually, I should clarify: a user can have many consumers if they have multiple tabs open, but it’s fun to call them sheep)

CHANNEL: The last of the C starting words! Channels are what our consumers can subscribe to. Think of these as the Action Cable version of your Controller. Your consumer should be subscribed to at least one channel.

SUBSCRIBER: When a consumer subscribes to a channel they are a subscriber now. Their name has changed and we must call them subscribers henceforth.

PUB/SUB: This is just the way communication is referred to in Action Cable. A Person can send information (publish) to a group of recipients (subscribers).

BROADCASTINGS: This is just an extension of Pub/Sub, except anything sent is immediately pushed to the consumer.

That was a lot! But let’s dive into how it all works together.

Channels are the bread and butter of action cable. The main thing. Rails is nifty because it sets up a default parent channel for you that looks something like this:

module ApplicationCableclass Connection < ActionCable::Connection::Baseendend

After this you can go ahead and make your channels for what you’re creating. So if you were making an online game of some kind, you could have a channel for the individual games:

class GamesChannel < ApplicationCable::Channeldef subscribed

We've done it! We’ve action cabled! Well… sort of. We have a simple channel that can now be subscribed to. We need to show how you can get all up in that subscription in the front end.

On your client side you can import a consumer directly from Rails like so:

import { createConsumer } from "@rails/actioncable"

export default createConsumer()

and then you can import the consumer wherever you’d like

import consumer from "./consumer"

consumer.subscriptions.create({ channel: "GamesChannel"})

Ok we’re all subscribed! Now all there is to do is broadcast something. So you can do this all the way back in our channel that we made earlier. In fact, you can do it within that same subscription definition we made in that channel. Here’s the games channel again, but with a little bit extra added in:

class GamesChannel < ApplicationCable::Channeldef subscribedstream_from "games:#{params["game_id"]}"end

Then elsewhere in your code you can broadcast from this channel


Ok NOW we’ve done it! We’ve action cabled!

So that was a VERY high-level rundown of how action cable and websockets works and how you can use them to make your apps fancier. I’d recommend checking out some of the documentation if you haven’t already


Full time software engineering student at Flatiron School