Question

我正在寻找使用Firebase创建社交媒体Feed。我的数据结构如下：

users: {
 uid: {
   ... // details  
  }
}

friends: { 
  uid: {
    friends: { // sub collection
      fuid: {
         ... // details
     }       
    }
  }
}`

posts: { 
  postId: {
    postedBy: uid
    ... // details
  }
}

现在我正在尝试从用户的所有朋友那里获取帖子，将其限制为最近的10个帖子，然后创建一个滚动指令，查询下一组10个帖子，以便用户不会必须查询并加载帖子^ N为朋友^ N在页面加载。但我不确定如何以这样的有效方式查询firebase，对于用户的朋友，然后是他们的帖子。

我有滚动指令工作，取自Jeff Delaney's Infinite Scrolling Lesson on AngularFirebase.com.但它只处理整个帖子（教程中的船只）集合，而没有选择性地在该集合中查询（检查用户是否是朋友）。

我能想到的唯一解决方案是查询所有用户的朋友帖子，将其存储在数组中，然后根据加载的最后一批帖子将结果加载到DOM中。如果用户有100个朋友，每个人有100个帖子，那么这似乎在长途飞行中效率非常低。

Answer 1

我最终通过利用Firebase功能解决了这个问题。我有两个集合，一个叫做Posts，另一个叫做Feeds。用户添加帖子时，该帖子将添加到Posts集合中。发生这种情况时，它将触发Firebase功能，然后该功能将获取发布用户的UID。

一旦有了UID，它就会查询另一个名为Friends/UID/Friends的集合，并获取其朋友的所有UID。

一旦具有UID，就会创建一个批量添加（如果用户有500个以上的朋友），然后将帖子添加到其朋友的Feeds/UID/Posts集合中。

我选择这条路线的原因有很多。

Firebase不允许您使用数组列表（用户的朋友）进行查询。
我不想过滤掉来自非朋友的帖子。
我不想将过多的数据下载到用户的设备。
我必须按从最新到最旧的顺序对结果进行分页。

通过使用上述解决方案，我现在能够查询Feeds/UID/Posts/集合，从而每次都返回下10个结果，而不会出现性能或数据问题。我无法完全解决的唯一限制是，由于该功能需要一些时间来启动，因此需要花费几秒钟将帖子添加到用户的个人供稿中。但这可以通过增加该特定功能的内存分配来缓解。

我也对已编辑和/或删除的帖子进行了上述操作。

Answer 2

如果我理解正确，那么您是在用户的朋友列表中为每个用户复制帖子吗？如果您的应用升级，我认为这不是一个好主意...目前，100k文档写入的成本为$ 0.18，所以：

想象一下，您的应用程序用户有1000个朋友。当他发布任何内容时，您正在数据库中写入1000次。想象您有1000个像他这样的活跃用户。您刚完成1.000.000次写入操作，并支付了1.80美元。

现在更糟：您可能在每个帖子上都有用户 displayName 的重复字段和 profileImageUrl 。想象一下，该用户的历史记录中有500条帖子，并且刚刚更改了个人资料图片。您必须为他的1000个朋友的供稿中的每个帖子更新一个字段，对吗？您将要做1000 * 500 = 500.000写操作，仅用于更新profileImageUrl！如果用户不喜欢该照片？他尝试了3张新照片，现在在10分钟内您已经在数据库中写入了2.000.000次写入。这意味着将向您收取3.60美元。似乎还不算太多，但是请注意，我们在同一时间谈论的是单个用户。 1000个用户在同一天内更改个人资料图片4次，您需要支付$ 3,600.00。看一下这篇文章：https://proandroiddev.com/working-with-firestore-building-a-simple-database-model-79a5ce2692cb#7709

Answer 3

我认为我为Firestore Social Feed查询提供了解决方案。不确定是否可以，但是在这里；

Friends集合将朋友UUID的列表作为数组保留在文档中。此集合中的每个文档都是针对用户的。因此，当用户登录时，我们首先拥有具有“读一次”功能的云功能的朋友列表吗？所有朋友的ID都在一个文档中。并且我们还对此文档添加了最后检查的时间戳。每当我们得到好友数组时，我们都会记录日期。
现在，云功能可以一一检查所有用户的帖子。据我了解最新的IN查询允许最多10个UUID的数组。因此，如果用户有100个朋友，查询将在十个回合中结束。现在我们有事可做。
我们将直接为每个用户创建一个集合，而不是直接提供这些帖子。我们会将所有收集到的数据记录在案，但是将其分成几天。假设我们已经在此usersfeed集合中有较旧的帖子（每天作为文档）。因此，我们最后一次查看了我们的好友文档。我们现在查询->上次检查日期。这样，我们只获取看不见的帖子并每天对其进行切片（如果它们属于课程的更多天）
因此，尽管这是在云功能上发生的，但我们已经提供了先前的提要文档。当集合有新文件时，firestore已经在听并且添加了吗？如果用户向下滚动，则会获得前几天的文档。因此，每个文档将具有不止一个将数据发布为map / array的信息。

我猜这可以节省许多读取计数。

Firebase Firestore，查询用户朋友的帖子

3 个答案: