Skip to content

Channels

On a Feathers server with a real-time transport (like Socket.io) configured, event channels determine which connected clients to send real-time events to and how the sent data should look.

This chapter describes:

Important

Channels functionality will not be available in the following two scenarios:

  • When you're making a rest-only API, not using a real-time adapter.
  • When you're using Feathers on the client. Only server-side Feathers has channel management.

Here are some example logic conditions where channels are useful:

  • Real-time events should only be sent to authenticated users
  • Users should only get updates about messages from chat rooms they joined
  • Only users in the same organization should receive real-time updates about their data changes
  • Only admins should be notified when new users are created
  • When a user is created, modified or removed, non-admins should only receive a "safe" version of the user object (e.g. only email, id and avatar)

Concepts

A channel is basically an array of connection objects. Each array is explicitly given a name. When using a real-time server transport and a new client connects, you can tell the server to explicitly add that client's connection object to any relevant channels. Any connection in a channel will receive all events that are sent to that channel. This allows clients to receive only their intended messages.

When using a real-time transport, the server pushes events (such as "created", "removed" etc. for a particular service) down to its clients. Using channels allows customizing which clients should receive each event. The client doesn’t subscribe to individual channels, directly, but rather subscribes to specific events like created, patched, custom events, etc, in which they are interested. Those events will only fire for a client if the server pushes data to one a channel to which the client has been added.

You can have any number of channels. This helps to organise how data is sent and to control the volume of data, by not sending things that aren't relevant.

The server can also change connection channel membership from time to time, eg. before vs after login.

The server needs to explicitly publish channels it is interested in sharing with clients before they become available.

Example

The example below shows a channels.js file illustrating how the different parts fit together:

ts
import type { RealTimeConnection, Params } from '@feathersjs/feathers'
import type { Application, HookContext } from './declarations'

export default function (app: any) {
  if (typeof app.channel !== 'function') {
    // If no real-time functionality has been configured just return
    return
  }

  app