拦截复杂业务逻辑的 Cloud Firestore 写入操作

Question

我需要在服务器端实现一些复杂的业务逻辑，以防止我的 Firestore 文档之间发生内部冲突。特别是我想防止在日历中重复预订。

我一直在研究将 Cloud Firestore 功能作为达到目的的一种手段。但是，所有的写操作事件似乎都是在事后触发，因此相关业务逻辑在损坏完成后不会被调用。

到目前为止，我只发现了一种模式来规避这个问题，那就是使用这样的间接集合：

1. 将操作写入“temporary_calendar”-collection
2. “temporary_calendar”-collection 的 onWrite 已触发
3. 检查新创建的临时日历项是否与现有的“日历”集合项冲突
4. 如果没有，请将临时项目写入“日历”-集合

这是实现此功能的标准方式吗？如果是这样，将冲突传达回原始客户端的好方法是什么？

Answer 1

您正在做的是一种实施内容审核的常用方法。非特权用户写入待处理队列，然后特权进程在该队列中提取内容并检查其有效性。如果内容有效，特权进程将其写入其最终位置。如果内容无效，则拒绝该内容。无论哪种方式，它都会在数据库的另一个位置为客户端写入响应，并使用用户知道的密钥（通常与编写请求时使用的客户端 ID 相同）。

所以你有三个集合：

1. calendar，其中包含实际的日历项。
2. requests，这是客户端编写请求的地方。您通常会将其设为只写集合，所有用户都可以在其中写入，但没有人（特权进程除外）可以读取。
3. responses，这是特权进程写入响应和客户端读取响应的位置。所以这是一个只读位置，只有特权进程可以写入。

requests 和 responses 中的文档使用相同的 ID，以便客户端可以编写其请求，然后监视对该特定请求的响应。