PubNub doesn't have a means of defining the type of 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 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:
Channel name depth
If your channel name is more than 3 levels deep (for example
name(lvl1).user(lvl2).event(lvl3).room(lvl4)), you must disable the Wildcard Subscribe feature in the Admin Portal to be able to publish to this channel. Otherwise, you will only be able to subscribe to it.
Consistent naming convention is particularly useful when managing access to multiple channels. When granting permissions, you can specify them as a regular expression rather than a list of channels.
Using RegEx limits the size of the token that will be sent in the grant request. This way you keep your grants simple and within the size limit (32 KiB). For more information about granting permissions, refer to Access Manager.
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.
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.