问题描述
我想知道在订阅更改并将其发布给用户方面存在哪些最佳实践。这是一个相当宽泛且措辞含糊的问题。因此，请允许我用一个例子来详细说明这一点。
想象一下以下（简化的）类似聊天的应用程序：
- 用户打开应用并看到主屏幕。
- 在此主屏幕上会获取并显示聊天组列表。
- 每个聊天组都有一个用户（成员）列表。
- 用户可以查看此成员列表。
- 每个用户/成员至少有一个可用的名字。
- 用户可以在设置中更改其名称。
- 现在是重要的部分：更改此名称后，查看成员列表的每个用户都应该实时看到名称更改。
我的问题涉及最后一点。
让我们创建一些非常简单的伪代码来模拟这样的事情。
客户至少应该订阅一些东西。所以我们可以这样写：
subscribetoEvent("userChanged")
后端应该使用正确的数据发布到此事件。所以是这样的：
publishDataForEvent("userChanged",{ userId: "9",name: "newname" } )
当然这段代码有问题。订阅用户现在获取每个用户的所有事件。相反，它应该只接收它感兴趣的用户的事件（即它当前正在查看的成员列表）。
这就是我想了解更多的问题。我可以想到几个解决方案：
方法一 客户端订阅该事件，并随它发送他当前正在查看的组的 ID。像这样例如：
subscribetoEvent("userChanged",{ groupId: "abc" })
像这样：
publishDataForEvent("userChanged",name: "newname" },{ groupIds: ["abc","def" })
由于用户订阅了一个id为“abc”的组，并且后端发布到多个组，包括“abc”，用户将收到事件。
方法二
与方法 1 相同。但我们将使用 userIds，而不是使用 groupIds。
subscribetoEvent("userChanged",{ myUserId: "1" })
像这样：
publishDataForEvent("userChanged",{ userId: "xyz",{ friendIds: ["1","2" })
这样做的一个优点是订阅可以更容易地重用。因此，用户不需要为他打开的每个组开始单独的订阅，因为他使用的是自己的 userId 而不是 groupId。
此方法的缺点是（与方法 1 类似，但可能更糟）可能需要大量 id 才能将事件发布到。
方法三
这个有点不同。
示例：
在客户端，应用程序收集与当前用户相关的所有用户。例如，这可以通过收集当前查看的组的所有用户 ID 来完成。
subscribetoEvent("userChanged",{ friendIds: ["9","10"] })
在后端，发布方法可以非常简单，如下所示：
publishDataForEvent("userChanged",{ userId: "9" } )
由于客户端订阅了 userId 为“9”的用户，因此在多个用户中，客户端将收到此事件。
我希望这些例子能让问题更清楚。我有一种感觉，我在这里错过了一些东西。像，主要的聊天应用程序公司，不能用这些方法之一做吗？我很想听听您对此的看法。
顺便提一下，我使用 graphql 作为后端。但我认为这个问题很笼统，不能让它发挥作用。
解决方法
- 用户可以在设置中更改其名称。
- 现在重要的部分是：更改此名称后，每个查看成员列表的用户都应该实时看到名称更改。
我假设用户可以通过表单更改他的名字。该表单的内容将与 HTTP-Reuqest 一起发送到后台脚本，该脚本将在数据库中进行更改，如
update <table> set field=? where userid=?
首选
这将是后端脚本连接到您的 Web 套接字服务器并发送类似消息的点。
{ opcode:'broadcast',task:'namechange',newname='otto',userid='47111' }
服务器将广播给所有连接的客户端
{task:'namechange',userid='4711' }
与 userid='4711' 有关系的所有客户现在都可以采取行动。
备选方案 1
如果您无法将后端脚本连接到 Web 套接字服务器，客户端可能会发送 { opcode:'broadcast',userid='47111' }
就在 FORM 传输到后端脚本之前。
这是不稳定的，因为如果后端出现任何问题，错误消息已经传递，或者客户端可能在消息发出之前死亡，那么没有人会注意到变化。