本地写入带有附加侦听器的 Firebase RTDB 或 Firestore 是否需要读取操作？

Question

在这个firestore官方guide中，它说

应用中的本地写入将调用快照侦听器 立即地。这是因为一个重要的特性叫做“延迟 补偿。”当您执行写入时，您的听众将 在数据发送到后端之前通知新数据

1. 所以 Firestore 客户端（发布此数据的）不会通过侦听器从服务器获取此数据？
2. 这是否仍会作为读取操作收费（以防数据未从服务器获取）？
3. 这个概念是否也适用于实时数据库？

我测试了一个客户端向/chats/chatRoomId/ 写入新对象，而同一客户端在/chats/chatRoomId/ 上有child_added 的侦听器。我关闭了互联网，仍然报告推送新数据正常（我猜是由于离线能力），并且听众也报告接收到新数据（即使没有服务器访问）

我想构建我的聊天应用程序的数据库，这样我就可以在给定here 和here 的聊天数据库结构中减少不必要的读取（如果有）的成本@FrankVanPuffelen 推荐来自 Firebase。

chats: {
  $roomId: {
    $messageId: {
      senderId: "..."
      message: "..."
    }
  }
}

示例：

考虑一个 1:1 聊天，其中 userA 和 userB（在不同的客户端上）在一个聊天室中，并且都向/chats/chatRoomId/ 添加了一个侦听器。现在，如果用户 A 在chatRoomId 中推送一条新消息，则用户 A 和 B 都将通过他们的侦听器收到这条新消息。这不是浪费带宽和/或 userA 的读取操作成本，因为他自己推送它，并且可能不需要从服务器获取它。

如果本地写入不会花费我为附加侦听器读取的服务器，我会将来自 userA 和 userB 的消息存储在同一路径 /chats/chatRoomId/ 和 recommended 中

否则，我想要一个 DB 结构，以便 userA 将只收听来自 userB 的消息。例如 userA 会将 userB 的新消息推送到 /chats/uid_A/uid_B/，userA 将监听 /chats/uid_B/uid_A/，其中 userB 正在为 userA 推送新消息。并且客户端会在本地合并这两条按时间排序的路径，得到一个聊天流。

它可能会为我节省 50% 的阅读量，并节省大量的 firebase 费用。

于 2019 年 3 月 5 日编辑：

为问题清晰添加图片：

Answer 1

1. 那么 Firestore 客户端（发布此数据的）不会通过侦听器从服务器获取此数据？

当您在本地写入一些数据时，将立即调用快照侦听器。这意味着您的听众将立即收到通知，因为您添加了一些新数据。但请记住，此操作发生在数据发送到 Firebase 服务器之前。

1. 这是否仍会作为读取操作收费（以防数据未从服务器获取）？

没有。只要您已缓存数据并且未将数据与 Firebase 服务器同步，您就无需为 Firestore 中的任何“读取操作”付费。

1. 这个概念也适用于实时数据库吗？

不，不是。 Firebase 实时数据库对 pricing 有不同的概念。

我想构建我的聊天应用程序的数据库，这样我就可以在来自 Firebase 的@FrankVanPuffelen 推荐的 here 和 here 的聊天数据库结构中减少不必要的读取（如果有的话）的成本。

这两个示例都是针对 Firebase 实时数据库的，并且都说明了创建聊天应用的一种非常好的方法。如果您考虑在某个时候尝试将 Cloud Firestore 用于聊天应用程序，您可以在此处找到有关如何创建完整且实用的 Firestore Chat App 的教程。

我也认为您可能对以下文章感兴趣：

• https://medium.com/firebase-tips-tricks/how-to-drastically-reduce-the-number-of-reads-when-no-documents-are-changed-in-firestore-8760e2f25e9e