Skip to content

Pusher Channels

Pusher Channels is a hosted way to tell an open app that something changed. Your app still saves the records and decides which people can receive each update.

Visit Pusher Channels

Is this for a screen someone already has open?

Channels sends events to connected screens. For example, a dispatch board can update when a job is assigned. Pusher Beams is the separate push-notification product for messages delivered through device notification systems.

The Channels event can say a job changed. Your app decides what that means for the screen and keeps the actual job record.

How does the right board get the event?

Put each board’s events on its own private channel. A browser asks your server for permission to subscribe. Your server checks board membership before returning the authorization signature, which is proof for Channels that the subscription is allowed.

Keep the signing secret on the server. Listening for a particular event name in the browser does not keep other channel messages private. Publish only the data that everyone allowed on that channel may receive.

What does someone see if they join late or reconnect?

For an ordinary channel, get the current board from your app and use channel events to signal changes. When the client reconnects and its subscription succeeds again, read the saved state or request the missed records from your own service.

A cache channel can give new subscribers the last published event if a cached value exists. That is useful for a current status that fits in one message. It does not supply a list of everything the browser missed.

How can you prove the board catches up without replay?

Use a separate Channels app, made-up jobs and test accounts. Before connecting, confirm the browser uses the test app, authorization goes to the test server, and the saved board and any external actions use only disposable destinations. If any connection is unclear, trace it on paper without sending an event.

  1. Establish the starting state
    Open the isolated board as a member and check it already shows Unassigned before anyone changes the job. Confirm the private subscription succeeded.
  2. Miss an event on purpose
    Disconnect that test browser while another member changes the job to Assigned and saves it. Reconnect, wait for the subscription to succeed, and verify the app reads Assigned from saved data.
  3. Observe an actual refusal
    In a separate test browser, use a nonmember account to attempt the private subscription. Confirm the authorization request was refused. Make a second test change and verify a member sees it while the nonmember gets no job data. If no request was attempted, record that as untested.

Why can one update count as several messages?

Channels counts messages it receives through its API and copies it delivers to connected users. One incoming event delivered to five subscribers counts as six messages under that rule. Watch the number of simultaneous connections as well.

The Channels Sandbox plan lists 200,000 messages per day and 100 concurrent connections. Keep the job records and any history you need in your own storage. To move providers, replace the channel and authorization calls and retest initial load and reconnect.