我使用 pubnub 的强大功能开发了聊天应用程序，但我仍然对使用渠道的一些最佳做法和最坏做法感到困惑。
例如，作为最终用户，我与多个最终用户启动了多个聊天频道。我称之为聊天室的每个聊天会话。
在前端，我只订阅了我自己的用户名后的频道。就像每当我从对手用户那里收到新消息一样，在后端，它会发布到我的频道。
假设我的频道名称是 jhondoe 并且我订阅了它
因此，每当有人向我发送消息时，我都会收到带有房间唯一标识符的消息，该消息实际上应该属于哪个房间。目前这种方式运作良好。
我的意思是，我只订阅了一个频道，那就是我的用户名。
因此，每当我收到任何人的消息时，我都会收到此订阅频道的通知。
我的困惑：
我是否应该为每个聊天室创建频道以接收消息。
假设我在 10 个聊天室，那么我应该为每个聊天室创建 10 个独特的频道，还是应该只创建/订阅一个频道来向我发送消息？
最佳做法是什么？
答案 0 :(得分：0)
首先阅读Overview in Channels docs。它给出了将单个通道用于特定目的的一些提示以及通道名称的规则。因此，在大多数用例中，是的，每个聊天室都有一个频道，无论是 1-1、群组还是广播类型的聊天。
原因是，当您fetch messages from storage时，您可以获得该频道参与者的整个对话，而不必从多个频道中提取消息并确定哪些属于同一对话，然后有其他频道中消息的可见性。但是还有一些更高级的设计模式，其中多个频道可用于给定的对话/聊天室。
PubNub 解决方案架构师团队已经记录了一些更多的 common advanced channel topologies，但应仅在必要时使用。
应该深思熟虑的是如何命名频道。 频道命名约定是您在设计 PubNub 应用程序时要做出的五个最重要的决定之一。
利用具有战略性频道名称的 PubNub 功能
PubNub 没有定义渠道类型的方法，但客户的用例将决定渠道的使用方式、渠道的用途以及通过这些渠道发送的消息类型。下面是一些常见的例子：
...还有更多
虽然可以只使用 UUID 生成器来命名频道，但 UUID 的随机性会阻止开发人员利用许多 PubNub 功能。因此，建议提供一个前缀来标识通道的用途或将通过这些类型的通道发送的消息类型。在该前缀后面加上“点”字符将进一步增强频道名称相对于通配符行为的实用性，并具有多个 PubNub 功能，包括：
一个好的默认通道命名约定是
[channelType].[channelID]，其中 channelID 可以是聊天室名称、用户 ID、设备 ID、事件 ID、地区、部门、客户 ID 或任何适合用例的名称。示例频道名称可能如下所示：
您甚至可以使用多个实体来构建完整频道名称的 channelID 部分。例如，您可以使用事件 ID 和房间 ID 或事件 ID 和客户 ID 的组合：
应该考虑使用的分隔符，因为点是特殊的，并且仅对第二级的 PN 特征真正有用：foo.bar 与 foo.bar.baz。换句话说，对于Function channel binding 和Access Manager grants，您实际上只能利用foo.* 而不能利用foo.bar.*。
但是，对于大多数用例，在 channel type 前缀后使用点是最好的选择，因为您很可能希望有一个特定的函数来处理该类型的通道上的所有消息，或者没有功能。
有时您希望每个客户或每个事件都有不同的功能实现，因此这会影响该点的位置。