要构建类似于RethinkDB的实时功能,Azure中的高级服务器端设计会是什么样子?
使用DocumentDB作为数据存储以及Change Feed似乎是合乎逻辑的起点,但下一步是什么?乍一看,改变Feed处理器库似乎与解决这个问题相关,但通过this article阅读让我觉得它是为其他东西设计的 - 分配工作量。此外,无法查询/过滤更改Feed似乎是一个障碍。
以下是RethinkDB docs:
的示例假设您有一个包含多个客户发布的聊天应用程序 消息到不同的聊天室。您可以创建订阅的订阅源 发布到特定房间的消息:
r.table('messages').filter( r.row('room_id').eq(ROOM_ID) ).changes().run(conn, callback)
我要问的是我如何使用DocumentDB和Change Feed来实现这样的目标。我不是在寻找一个完整的解决方案,我正在寻找一个高水平的设计策略来推动我的思考并尝试正确的方向。
因此,在DocumentDB doable(可取)之上构建这种类型的功能,如果是,那么Azure将使用哪些“部分”?这个解决方案会是什么样的?
更新:将引用从Firebase更改为RethinkDB,因为它更符合我要求的内容(服务器端与客户端直接与数据库通信)。
注意:对于那些希望关闭此问题的人,我现在无法更具体,因为这就是我所处的位置。如果你真的觉得这种类型的问题不适合Stack Overflow,我会很感激我可以在哪里发布它。
答案 0 :(得分:0)
更改Feed会对文档进行所有更改。今天,您无法为特定事件订阅更改源或过滤Feed。您必须过滤函数中的事件。
Azure功能与Change Feed的集成非常好。它简化了您的开发。