channels

19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Channels are implemented using Phoenix Channels

Channels are implemented using Phoenix Channels which uses Phoenix.PubSub with the default Phoenix.PubSub.PG2 adapter. The PG2 adapter uses Erlang process groups to implement the PubSub model where a publisher can send messages to many subscribers.

Topics are channel identifiers

Topics are the names of channels. They are strings used to identify a channel.

Events are types of messages

Events are the type of messages that can be sent and received in a channel.

Payload is the actual data sent and received

Payload is the actual data that is sent and received in a channel, which the user will act upon.

Concurrent Connections metric

Concurrent Connections is the total number of channels subscribed for all clients.

Public channels allow any user to subscribe

For public channels, any user can subscribe to the channel, send and receive messages without authorization controls.

Private and public channels with same topic are unique

If you have a private channel and a public channel with the same topic name, Realtime sees them as unique channels and won't send messages between them.

Channel definition and purpose

Channels are the foundation of Realtime and function as rooms where clients can communicate. Each channel is identified by a topic name and can be configured as public or private.

Create channel with topic name

Create a channel using supabase.channel(topic_name, config). Example: supabase.channel('room:lobby:messages', { config: { private: true } }). The topic name is a string identifier for the channel.

Private channel configuration recommended for production

Private channels should be used for production applications to ensure proper security and authorization. Set private: true in the channel config.

Channel naming convention pattern

Use the pattern scope:id:entity for channel topics. Examples: room:123:messages for messages in room 123, game:456:moves for game moves for game 456, user:789:notifications for notifications for user 789.

Clean up subscriptions by unsubscribing

Always unsubscribe when done with a channel to free up resources. In TypeScript: supabase.removeChannel(channel) or use cleanup in useEffect. In Flutter: _channel?.unsubscribe() in dispose(). In Swift: await channel?.unsubscribe() in onDisappear. In Python: channel.unsubscribe(). In C#: supabase.Realtime.Remove(channel).

Channel Restrictions setting

The 'Channel Restrictions' setting allows you to toggle between allowing public channels or restricting Realtime to use only private channels with Realtime Authorization.

Channels per connection limit

Channels per connection limit is 100 for most plans.

Rate of Channel Joins report

The Rate of Channel Joins report monitors how fast clients are joining Realtime channels over time. A channel join occurs whenever a client subscribes to a channel topic to receive real-time updates. Each client connection can join multiple channels (up to 100 per connection for most plans), and the join rate measures how many subscriptions happen per second across the entire project. Essential for understanding channel subscription patterns and identifying when approaching channel join rate limits. Available for all plans.

Channel joins per second limits by plan

Channel joins per second limits vary by plan: Free plan allows 100 joins per second, Pro plan allows 500 joins per second, Pro no spend cap allows 2,500 joins per second, Team plan allows 2,500 joins per second, and Enterprise plan allows 2,500 joins per second.

phx_join event structure and configuration

The phx_join event is the initial message required to join a channel. The payload contains a `config` object with nested configuration for broadcast, presence, postgres_changes, and a privacy flag. Broadcast config includes `ack` (boolean), `self` (boolean), optional `replay` object with `since` (timestamp in ms) and `limit` (number), and optional `replication_ready` (boolean). Presence config includes `enabled` (boolean) and `key` (string, or UUID if not specified). Postgres_changes is an array of objects each with `event` (INSERT|UPDATE|DELETE|*), `schema` (supports * wildcard), `table` (supports * wildcard), optional `filter` (column=operator.value expression with AND combining, supports negation with not. prefix, reserved characters must be double-quoted), and optional `select` array of column names. The payload also accepts optional `access_token` for authentication.

phx_leave event

The phx_leave event is sent by client to leave a channel. It can be used to clean up resources or stop listening for events. The payload should be an empty object.

phx_join example with protocol version 2.0.0

Example phx_join message in protocol 2.0.0 format: ['3', '5', 'realtime:chat-room', 'phx_join', { 'config': { 'broadcast': { 'ack': false, 'self': true, 'replay': { 'since': 1763407103911, 'limit': 10 } }, 'presence': { 'key': 'user_id-827', 'enabled': true }, 'postgres_changes': [], 'private': true } }]

Give your agent this brain