Action Cable

📡 Action Cable

🔗 Connections and Channels

Copy# app/channels/application_cable/connection.rb
module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = find_verified_user
    end

    private

    def find_verified_user
      if (user = User.find_by(id: cookies.encrypted[:user_id]))
        user
      else
        reject_unauthorized_connection
      end
    end
  end
end

A Connection is established once per browser tab, the moment the WebSocket handshake happens — it's where authentication lives, reusing the same encrypted session cookie rails2-1 already set during a normal HTTP login. identified_by :current_user declares that every message flowing through this connection knows which user it belongs to, and reject_unauthorized_connection refuses the handshake entirely for anyone who fails the check — the WebSocket equivalent of rails2-1's require_login before_action.

A single Connection can host many Channels — one per feature that needs real-time updates:

Copy# app/channels/comments_channel.rb
class CommentsChannel < ApplicationCable::Channel
  def subscribed
    post = Post.find(params[:post_id])
    stream_for post
  end
end

stream_for post subscribes this client to a stream scoped to one specific post — Action Cable derives a unique stream identifier from the object automatically, so every browser tab currently viewing that post's comments joins the same stream, and tabs viewing a different post don't.

📢 Broadcasting

Copy# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post
  after_create_commit :broadcast_comment

  private

  def broadcast_comment
    CommentsChannel.broadcast_to(post, CommentSerializer.new(self).as_json)
  end
end

after_create_commit is a callback (from Course 1's validations/callbacks chapter, rails1-7) that fires only after the database transaction actually commits — broadcasting before that point risks telling clients about a comment that a later rollback then undoes. broadcast_to(post, ...) pushes the payload to every client streaming that specific post, reusing the exact same CommentSerializer Chapter 5 wrote for the JSON API — one source of truth for "what a comment looks like," whether it arrives via a REST request or a live broadcast.

💻 The Client Side

Copy// app/javascript/channels/comments_channel.js
import consumer from "./consumer"

consumer.subscriptions.create(
  { channel: "CommentsChannel", post_id: postId },
  {
    received(data) {
      appendCommentToPage(data)
    }
  }
)

The client subscribes with the same post_id param the server's subscribed method reads, and received fires every time a broadcast arrives on that stream — no polling, no manually re-fetching the comments list.

📜 Action Cable vs Socket.IO

The concepts map closely — a Socket.IO "room" and an Action Cable "stream" solve the same "only these clients get this message" problem. The organizational difference is Rails' usual one: a dedicated channel class per feature (CommentsChannel, NotificationsChannel) instead of a flat set of event name strings on one shared connection.

💻 Coding Challenges

🎯 What's Next

Next chapter: Hotwire — Turbo & Stimulus — how modern Rails apps add interactivity to server-rendered HTML without reaching for a full frontend framework.