您能否验证我使用 Firebase 管理用户通知系统的方法？
基本上我想拥有用户特定的频道以及更通用的频道来保存通知。如果用户之前没有查看这些通知，这些通知将出现在 Intranet 上。
作为服务器端操作的想法将使用 REST API 为特定用户或向所有人广播更新 Firebase 端点。我可以轻松地将特定用户消息标记为已读，因此不会再次显示它们，这是我正在努力解决的一般广播。
我可以在一般广播中添加一个标志（用户 ID）以指示其已读取，但我担心性能，因为客户端必须检查历史广播消息中是否存在此标志。我可以添加一个用户 ID 来创建一个应该更快的新端点。
例如 /notification/general/ - 包含消息，这会触发客户端，然后检查 /users/USERID/MessageID 是否存在，如果它不显示消息并创建此端点。
有什么我遗漏的东西还是最好的方法？
消息总是按顺序消费吗？如果是这样，您可以让每个客户端记住它在每个公共频道中读取的最后一条消息的 ID。然后，您可以在队列上使用“startAt”将其限制为仅接收新消息。
如果它们没有按顺序使用，那么您将需要某种方式来存储有关哪些已读取和哪些未读取的数据。也许您可以将每条消息发送到每个人的个人队列，然后让每个用户删除已读消息。
既然已经有单独的用户消息，为什么不单独将广播发送给每个人（想想电子邮件），而不是尝试存储一个副本并找出谁阅读了它。
为了减少批量，您可以单独存储消息内容，并将 id 简单地存储在用户的队列中。然后，在查看它们时，您可以为每个用户标记它们，而不会增加任何复杂性。
100k 的用户每天收到 100 条消息，包括广播，使用标准的 Firebase ID（大约 20 个字符），每年有 210,000,000 个字符（即，对于数据库来说没有任何意义，可能仍然远远少于存储消息正文），假设它们永不过期并被删除。