Action Cable та WebSocket у Rails: Повний посібник для технічних співбесід 2026

Action Cable додає підтримку WebSocket безпосередньо у фреймворк Rails, дозволяючи створювати функції реального часу — чат, сповіщення, живі дашборди — без зовнішніх залежностей. На технічних співбесідах 2026 року знання внутрішніх механізмів Action Cable, від життєвого циклу з'єднання до масштабування у продакшені, відрізняє сильних кандидатів від решти.

Основи протоколу WebSocket у контексті Rails

Протокол WebSocket (RFC 6455) встановлює постійний, повнодуплексний канал зв'язку через одне TCP-з'єднання. На відміну від циклу запит-відповідь у HTTP, WebSocket підтримує відкрите з'єднання, де як клієнт, так і сервер можуть надсилати повідомлення у будь-який момент.

Action Cable обгортає цей протокол у зручну для Rails абстракцію. Сервер обробляє оновлення з'єднання до WebSocket за адресою /cable, керує автентифікацією з'єднань та маршрутизує повідомлення через канали. Клієнтська бібліотека JavaScript автоматично створює та керує підписками.

Типовий HTTP-запит завершується за мілісекунди та закриває з'єднання. З'єднання WebSocket залишається відкритим хвилини, години або протягом усієї сесії. Ця фундаментальна різниця визначає кожне архітектурне рішення в Action Cable.

Архітектура Action Cable: з'єднання, канали та підписки

Action Cable дотримується багатошарової архітектури з трьома основними абстракціями: з'єднання обробляють автентифікацію, канали інкапсулюють бізнес-логіку, а підписки зв'язують споживачів із конкретними каналами.

# 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
      # Cookies are available in WebSocket handshake
      if verified_user = User.find_by(id: cookies.encrypted[:user_id])
        verified_user
      else
        reject_unauthorized_connection
      end
    end
  end
end

Клас з'єднання виконується один раз під час рукостискання WebSocket. Автентифікація відбувається саме тут — не в окремих каналах. Оголошення identified_by реєструє ідентичність користувача, роблячи її доступною у всіх підписках каналів цього з'єднання.

# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
  def subscribed
    room = ChatRoom.find(params[:room_id])
    # Authorization: verify user belongs to this room
    if room.members.include?(current_user)
      stream_for room
    else
      reject
    end
  end

  def receive(data)
    message = ChatMessage.create!(
      room_id: params[:room_id],
      user: current_user,
      body: data["body"]
    )
    ChatChannel.broadcast_to(
      message.room,
      { id: message.id, body: message.body, user: current_user.name }
    )
  end

  def unsubscribed
    # Cleanup: mark user as offline
    AppearanceTracker.mark_offline(current_user)
  end
end

Канали визначають три callback-и життєвого циклу: subscribed, receive та unsubscribed. Метод stream_for прив'язує підписку до конкретного екземпляра моделі, створюючи потік з простором імен. Broadcasting до цього потоку доставляє повідомлення кожному підключеному підписнику.

Підписки на стороні клієнта у JavaScript

Клієнтський consumer підключається до сервера Action Cable та керує підписками. Кожна підписка відповідає каналу на стороні сервера.

import consumer from "./consumer"

const chatChannel = consumer.subscriptions.create(
  { channel: "ChatChannel", room_id: roomId },
  {
    connected() {
      // Called when the subscription is ready
      console.log("Connected to chat room", roomId)
    },

    disconnected() {
      // Called when the subscription is closed
      console.log("Disconnected from chat room")
    },

    received(data) {
      // Called when data is broadcast to the channel
      const messageList = document.getElementById("messages")
      messageList.insertAdjacentHTML("beforeend",
        `<div class="message"><strong>${data.user}</strong>: ${data.body}</div>`
      )
    },

    sendMessage(body) {
      // Calls ChatChannel#receive on the server
      this.perform("receive", { body: body })
    }
  }
)

Callback received спрацьовує щоразу, коли сервер виконує broadcast до підписаного потоку. Метод perform надсилає дані від клієнта до сервера, викликаючи відповідний метод каналу.

Solid Cable у Rails 8: pub/sub на основі бази даних

Rails 8 представляє Solid Cable як частину "Solid Trifecta" разом із Solid Queue та Solid Cache. Solid Cable замінює Redis як бекенд pub/sub, зберігаючи повідомлення у таблиці бази даних.

# config/cable.yml (Rails 8 default)
development:
  adapter: solid_cable

production:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

Solid Cable працює шляхом запису кожного broadcast-повідомлення у таблицю бази даних та опитування нових повідомлень із налаштовуваним інтервалом. Стандартний інтервал опитування 100 мс забезпечує доставку майже в реальному часі для більшості застосунків.

Компроміс очевидний: Solid Cable усуває інфраструктурну залежність (Redis) ціною дещо більшої затримки та навантаження на базу даних. Для застосунків, що вже використовують PostgreSQL або MySQL, цей компроміс часто виправданий. Для високочастотного broadcasting (тисячі повідомлень за секунду) Redis залишається кращим вибором.

# config/database.yml (Rails 8 multi-database)
production:
  primary:
    <<: *default
    database: myapp_production
  cable:
    <<: *default
    database: myapp_cable_production
    migrations_paths: db/cable_migrate

Solid Cable використовує виділену базу даних, щоб уникнути конкуренції з основною базою. Це розділення запобігає впливу опитування повідомлень на запити застосунку.

Патерни broadcasting та тригери на стороні сервера

Broadcasting з моделей, фонових завдань та контролерів охоплює три найпоширеніші патерни у продакшн-застосунках Rails.

# Broadcasting from a model callback
class Notification < ApplicationRecord
  belongs_to :user
  after_create_commit :broadcast_to_user

  private

  def broadcast_to_user
    ActionCable.server.broadcast(
      "notifications_#{user_id}",
      { id: id, title: title, read: false }
    )
  end
end

# Broadcasting from a background job
class DashboardUpdateJob < ApplicationJob
  queue_as :default

  def perform(dashboard_id)
    dashboard = Dashboard.find(dashboard_id)
    stats = dashboard.compute_stats
    ActionCable.server.broadcast(
      "dashboard_#{dashboard_id}",
      { stats: stats, updated_at: Time.current.iso8601 }
    )
  end
end

Callback-и моделей підходять для простих сповіщень, що викликаються змінами записів. Фонові завдання обробляють важчі обчислення — розрахунок статистики дашборду чи агрегацію даних — без блокування циклу запиту. Сам broadcast завжди легкий: він серіалізує payload та публікує його до адаптера.

Turbo Streams та інтеграція з Action Cable

Rails 8 із Hotwire використовує Action Cable як транспортний рівень для Turbo Streams, забезпечуючи оновлення DOM у реальному часі без написання власного JavaScript.

# app/models/message.rb
class Message < ApplicationRecord
  belongs_to :chat_room
  # Automatically broadcasts append to subscribers
  broadcasts_to :chat_room
end

# app/views/chat_rooms/show.html.erb
<%= turbo_stream_from @chat_room %>
<div id="messages">
  <%= render @chat_room.messages %>
</div>

Макрос broadcasts_to генерує callback-и after_create, after_update та after_destroy, які транслюють фрагменти Turbo Stream через Action Cable. Хелпер turbo_stream_from на стороні клієнта підписується на відповідний потік. Створення нового повідомлення автоматично додає його відрендерений partial до DOM кожного підключеного клієнта.

Цей патерн зводить функції реального часу до оголошення в моделі та хелпера у view — без власних каналів, без JavaScript-обробників, без ручної маніпуляції DOM.

Масштабування Action Cable у продакшені

Продакшн-деплоймент потребує ретельного розгляду вибору адаптера, лімітів з'єднань та горизонтального масштабування.

# config/cable.yml — Redis adapter for high-scale production
production:
  adapter: redis
  url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>
  channel_prefix: myapp_production

Redis виступає основою pub/sub, забезпечуючи доставку повідомлень, опублікованих в одному процесі Rails, підписникам, підключеним до будь-якого іншого процесу. Без Redis (або Solid Cable) адаптер async обмежує broadcasting одним процесом — що непридатно для будь-якого багатопроцесного чи багатосерверного деплойменту.

Ліміти з'єднань залежать від сервера. Puma з Action Cable обробляє з'єднання WebSocket в тому ж процесі, що й HTTP-запити. Кожен WebSocket утримує постійне з'єднання, споживаючи потік (або файбер у Ruby 3.x з планувальниками на основі файберів). Типова конфігурація Puma з 5 потоками та 4 воркерами може обробити приблизно 200 одночасних з'єднань WebSocket до насичення.

Для застосунків, що потребують тисяч одночасних з'єднань, AnyCable замінює Ruby WebSocket-сервер на сервер, написаний на Go, що обробляє з'єднання на рівні протоколу, водночас перенаправляючи логіку каналів назад до Rails через gRPC. Ця архітектура підтримує понад 10 000 одночасних з'єднань на вузол.

Тестування каналів Action Cable

Rails надає ActionCable::Channel::TestCase для модульного тестування каналів та ActionCable::Connection::TestCase для тестування автентифікації з'єднань.

# test/channels/chat_channel_test.rb
require "test_helper"

class ChatChannelTest < ActionCable::Channel::TestCase
  test "subscribes to a valid room" do
    room = chat_rooms(:general)
    user = users(:alice)
    stub_connection current_user: user

    subscribe room_id: room.id

    assert subscription.confirmed?
    assert_has_stream_for room
  end

  test "rejects subscription for unauthorized user" do
    room = chat_rooms(:private)
    user = users(:outsider)
    stub_connection current_user: user

    subscribe room_id: room.id

    assert subscription.rejected?
  end

  test "broadcasts messages to room subscribers" do
    room = chat_rooms(:general)
    stub_connection current_user: users(:alice)
    subscribe room_id: room.id

    assert_broadcast_on(room, hash_including(body: "Hello")) do
      perform :receive, body: "Hello"
    end
  end
end

Метод stub_connection налаштовує контекст з'єднання без реального WebSocket. assert_has_stream_for перевіряє прив'язку до потоку. assert_broadcast_on перехоплює broadcast-и в блоці, підтверджуючи доставку правильного payload до правильного потоку.

Типові питання на співбесідах про Action Cable

Технічні питання на співбесідах щодо Action Cable зазвичай перевіряють розуміння протоколу, архітектурних рішень та продакшн-проблем.

Як Action Cable автентифікує з'єднання? Автентифікація відбувається у ApplicationCable::Connection#connect під час рукостискання WebSocket. У цей момент доступні cookie з HTTP-сесії. Автентифікація на основі токена передає токен як параметр запиту в URL WebSocket і валідує його в connect.

Що відбувається, коли з'єднання WebSocket обривається? Клієнтська бібліотека реалізує автоматичне повторне підключення з експоненційним відступом. На стороні сервера unsubscribed спрацьовує для кожного каналу, на який було підписано це з'єднання. Очищення стану (позначення користувачів як офлайн, звільнення блокувань) належить до unsubscribed.

Коли варто використовувати Solid Cable замість Redis? Solid Cable підходить для застосунків з помірними потребами реального часу (менше 100 повідомлень на секунду), що хочуть уникнути інфраструктури Redis. Redis залишається необхідним для сценаріїв із високою пропускною здатністю або коли критична затримка доставки менше 10 мс.

Висновок

• Action Cable обгортає протокол WebSocket у конвенції Rails із з'єднаннями, каналами та підписками як основними абстракціями
• Автентифікація належить до ApplicationCable::Connection; авторизація — до callback-ів subscribed в окремих каналах
• Solid Cable у Rails 8 усуває залежність від Redis, використовуючи базу даних для pub/sub — підходить для застосунків із помірною пропускною здатністю
• Turbo Streams використовують Action Cable для автоматичних оновлень DOM у реальному часі з мінімальним кодом
• Масштабування у продакшені потребує Redis або Solid Cable для багатопроцесних деплойментів; AnyCable підтримує понад 10 000 з'єднань, переносячи керування WebSocket на Go
• Тестування каналів використовує stub_connection, assert_has_stream_for та assert_broadcast_on — без потреби у реальних з'єднаннях WebSocket
• Практикуйте питання співбесіди з Action Cable та WebSocket, щоб закріпити ці концепції цілеспрямованими вправами