PubNub doesn't have a means of defining the type of a particular channel, but many use cases dictate their purpose and the types of messages being sent over those channels:
- Message broadcasting, such as speaker to audience announcements.
- Private/direct chat: typical 2 person chat sessions.
- Group chat: 3 or more participant chat sessions.
- Live event chat: hundreds to tens of thousands of users chatting concurrently.
- Control signals: controlling devices or client apps.
- Signal protocol, for example, getting clients connected over audio/video.
- Inbox messages, such as invitation for the user to chat or notification to the user of new messages/activity.
Descriptive Naming with Prefixes
While it's possible to use a UUID generator to name channels, the randomness of a UUID format prevents the developer from taking advantage of many PubNub features.
We recommend that you provide a prefix that identifies the purpose of the channel or the types of messages that are sent over those types of channels.
Following that prefix with a
. character further enhances the usefulness of the channel name concerning the wildcard features with several PubNub features, including:
- Wildcard Subscribe
- Wildcard Grant
- Wildcard Channel Function Binding
- Presence ACL configuration (an advanced means for configuration presence based on channel naming patterns)
For more information, refer to Channel Subscriptions.
Recommended Naming Convention
A good default channel naming convention would be
channelID could be the name of the chat room, a user ID, device ID, an event ID, region, department, customer ID, or whatever is appropriate for the use case. For example:
You might even use multiple entities to construct the
channelID portion of the full channel name. For example, a combination of event ID and room ID or event ID and customer ID:
You should consider the delimiters that you use because the
. is a special character and is only useful for PubNub features at the second level:
In other words, you can only leverage
foo.* but not
foo.bar.* for function channel binding and Access Manager auth grants.
For most use cases, however, using a
. after the channel type prefix is the best option since you most likely want to have a specific Function that handles all messages over that type of channel or possibly no Function at all.
There are occasions when you want to have a different Function implementation per customer or event, so that would factor into where that
. is positioned.
For more detailed channel naming convention recommendations tailored to your specific requirements, feel free to contact your PubNub account manager and solution architect.