Ruby on Rails Documentattion

# Action Cable

  • Introduction

    In many modern web applications, WebSockets are used to implement realtime, live-updating user interfaces. When some data is updated on the server, a message is typically sent over a WebSocket connection to be handled by the client. WebSockets provide a more efficient alternative to continually polling your application's server for data changes that should be reflected in your UI.

    For example, imagine your application is able to export a user's data to a CSV file and email it to them. However, creating this CSV file takes several minutes so you choose to create and mail the CSV within a queued job. When the CSV has been created and mailed to the user, we can use event broadcasting to dispatch event that is received by our application's JavaScript. Once the event is received, we can display a message to the user that their CSV has been emailed to them without them ever needing to refresh the page.

    To assist you in building these types of features, Rails makes it easy to "Actioncable" your server-side events over a WebSocket connection. Broadcasting your Rails events allows you to share the same event names and data between your server-side Rails application and your client-side JavaScript application.

    The core concepts behind broadcasting are simple: clients connect to named channels on the frontend, while your Rails application broadcasts events to these channels on the backend. These events can contain any additional data you wish to make available to the frontend.

  • Terminology

    Connections

    Connections form the foundation of the client-server relationship. A single Action Cable server can handle multiple connection instances. It has one connection instance per WebSocket connection. A single user may have multiple WebSockets open to your application if they use multiple browser tabs or devices.

    Consumers

    The client of a WebSocket connection is called the consumer. In Action Cable, the consumer is created by the client-side JavaScript framework.

    Channels

    Each consumer can, in turn, subscribe to multiple channels. Each channel encapsulates a logical unit of work, similar to what a controller does in a typical MVC setup. For example, you could have a ChatChannel and an AppearancesChannel, and a consumer could be subscribed to either or both of these channels. At the very least, a consumer should be subscribed to one channel.

    Subscribers

    When the consumer is subscribed to a channel, they act as a subscriber. The connection between the subscriber and the channel is, surprise-surprise, called a subscription. A consumer can act as a subscriber to a given channel any number of times. For example, a consumer could subscribe to multiple chat rooms at the same time. (And remember that a physical user may have multiple consumers, one per tab/device open to your connection).

    Pub/Sub

    Pub/Sub (opens new window) or Publish-Subscribe refers to a message queue paradigm whereby senders of information (publishers), send data to an abstract class of recipients (subscribers), without specifying individual recipients. Action Cable uses this approach to communicate between the server and many clients.

    Broadcastings

    A broadcasting is a pub/sub link where anything transmitted by the broadcaster is sent directly to the channel subscribers who are streaming that named broadcasting. Each channel can be streaming zero or more broadcastings.

← Security →