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!

WebSocket

Let’s talk sockets. Web sockets specifically. WebSocket works as an alternative to HTTP. HTTP is your front end saying “Hey backend. I need this handful of things please grab them and then we’re done for now.” Websocket is your front end and backend saying “Hey…. let’s just hang out and talk for a little bit”. HTTP is you eating food and closing your mouth. WebSocket is you eating food and keeping your mouth open for more food. Is that the best analogy? Probably not! Here are some real diagrams for reference:

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

Action cable exists for one reason only and that’s to make WebSocket easier to use in both your backend and front end. It also introduces a lot of terminologies that are specific unto itself and for whatever reason, a lot of them start with the letter Cso let’s go through a bit of what that is.

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 ApplicationCable
class Connection < ActionCable::Connection::Base
end
end

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::Channel
def subscribed
end
end

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::Channel
def subscribed
stream_from "games:#{params["game_id"]}"
end
end

Then elsewhere in your code you can broadcast from this channel

ActionCable.server.broadcast("games:#{data["game_id"]}"

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

https://guides.rubyonrails.org/action_cable_overview.html