firebase - 使用 Firestore 作为 SQL 聚合的缓存

Question

我不确定这是否是问这个问题的地方，但我有一个最佳实践问题。

我有一个由 Salesforce 数据提供的仪表板服务，它显示本周执行的任务 X 的数量（X 是关闭的机会 - 赢得、创建的潜在客户等）。

目前，数据被定期提取并存储在 SQL 数据库中，该数据库映射到客户端应用程序调用以获取两个日期值之间的聚合的 REST API，并将通过 SF 的插入触发器由 Webhook 调用额外提供。

我想知道将 Firestore 集合用作聚合 SQL 的缓存是否是一个好主意，或者是否有更好的方法。我看到的好处是减少了我的 SQL 服务器上的流量，即时更新（如果“缓存”（Firestore）被更新，客户端的值也会立即更新）。

当从 SF 中提取数据或通过插入触发器/Webhook 接收到新记录时，我可以更新 Firestore 记录，客户端将立即收到更改。

我对 Firestore 文档的想法是

{
  user: "123",
  sfOwnerId: "124",
  sfTaskType: "Opportunities Closed Won This Week",
  count: 23
} 

这是一个好主意吗？那里有更好的吗？

提前谢谢你！

标签： firebasesalesforcegoogle-cloud-firestore

Answer 1

您存储聚合数据的策略是Firestore 文档建议的聚合策略，所以我认为这是一个非常可靠的想法。

另一种策略是仅将 Salesforce 数据存储在 Firestore 中，而不是聚合，并让客户端执行聚合。这可以通过订阅 Collection 查询的实时更新来实现。在此设置中，您将在回调中执行计算onSnapshot（假设您使用的是 Web 环境）。

这里的优势是可能会提高性能，因为 Cloud Functions 经常遭受“冷启动”延迟。

注意：本文档中的一些建议以所谓的冷启动为中心。函数是无状态的，执行环境往往是从头开始初始化的，称为冷启动。冷启动可能需要很长时间才能完成。最佳实践是避免不必要的冷启动，并尽可能简化冷启动过程（例如，通过避免不必要的依赖关系）。

资源