Question

构建CMS并尝试找出使用Firebase处理草稿的最佳方法。例如，站点管理员将编辑文档，这些文档将公开发布到站点。

起初，似乎完美的解决方案是拥有一个＆＃34; public＆＃34; property设置为true并通过安全规则强制执行，如下所示：

{
  "rules": {
    "documents": {
      "$id": {
        ".read": "data.child('public').val() == true"
      }
    }
  }
}

（如下文所述：https://www.firebase.com/docs/security/rule-expressions/data.html）

但显然文档是有缺陷的，因为在那个例子中我可以点击/文件，它会给我所有文件，无论公众＆＃39; ==是的。为了防止您必须将其更改为：

{
  "rules": {
    "documents": {
      ".read": false,
      "$id": {
        ".read": "data.child('public').val() == true"
      }
    }
  }
}

理想情况下，我能够为/ documents /公开一个简单的REST API端点，它只返回包含所有子属性的所有公共文档。

显然Firebase不支持过滤（这实际上就是我试图通过说＆＃34; SELECT * FROM文件WHERE public = true＆＃34;。

所以我看到两个选择：

选项1：保持REST API端点良好＆amp;通过将文件草稿存放在不同的地方（如/草稿/文件）来清洁。管理员将创建＆amp;使用自动保存编辑草稿文档，然后进行＆＃34;发布＆＃34;单击时按钮会将当前草稿复制到公共/文档。

选项2：没有/ documents的干净REST API端点，而是具有/ documentIndex，它只返回文档ID列表。然后客户端必须遍历每个documentIndex以在/ documents /：id处调用每个单独的文档端点。我担心这个选项的性能。此选项似乎在此处记录：Firebase data normalized. How should I fetch a collection based on this structure?但并未涵盖对REST API的影响。我使用的是AngularJS，但其他客户可能希望以其他方式使用文档数据（因此我也希望通过REST API公开数据）。

思想？

Answer 1

这两种方法都很好。当结构和排序经常变化或存在多种排序可能性时（例如，有时按日期排序，有时按排名排序的列表），索引更灵活。额外的听众对性能影响不大（通常不会超过获取字节所需的时间）。

在路径之间移动数据（一种队列或文件夹方法）可能很适合您的需求，因为您已经强调了REST访问。如果，与您的特定用例不同，一个人想要批量移动大量数据（几百兆），那么这不是一个好方法，因为它需要在将数据写回客户端之前将数据写回到新路径。 / p>

如果您的目标是针对可能的其他客户进行优化，那么您需要首先确定这些客户是什么以及他们将如何连接。完全基于可能性做出任何明智的决定是很困难的。

在完全依赖REST进行任何优化之前，我首先尝试进行一些分析，看看它是如何执行的。您可能会发现这足以满足您的用例。

草稿＆amp;在Firebase中发布

1 个答案: