CQRS和WebSockets

Question

當我們必須將推送更新功能添加到基於CQRS的系統時，似乎有意義讓「讀取」模型負責管理這些推送消息。當使用長輪詢和服務器事件時（大多數是單向的），這很有意義

但WebSockets是雙向持久通道。這是一個已經建立的連接，可用於獲取推送更新和發送命令。問題是WebSocket連接由於減少了延遲和狀態而變得非常方便，因爲很多事情都像自動完成搜索框一樣。乍一看，從技術角度來看，當已經有一個可用的通道就緒並準備就緒時，使用另一個端點（即：HTTP POST接收器）是沒有道理的。

哪裏可以找到啓用WebSocket端點的正確位置？

• 閱讀模式：是有道理的推送更新客戶端和像自動完成搜索框解答問題，但如果它接受「寫」，那就已經閱讀並在同一個地方更新模型試。

• 更新模型：接受客戶端輸入是有意義的。將推送更新發送到客戶端是有道理的，因爲它們是由其他客戶端輸入觸發的。但是對於搜索自動完成搜索等請求響應的東西是沒有意義的。

Answer 1

WebSockets是一個基礎設施問題。正如您指出的那樣，它們在某些情況下比原始HTTP具有實質優勢，但它們與您的域策略無關。

在我們的項目之一，我們發送的所有命令和查詢（包括觀察到的查詢）以上的WebSockets爲你提到的原因，但是這是抽象這些命令的作者和客戶端了。

撇開他們（略）更低的延遲在現代的網絡堆棧[*]我相信有兩個很明顯的地方，他們可以照

• 訂閱經典的酒吧/事件的子流，例如在聊天系統，或者來自某種用戶模型的事件流。
• 訂閱「可觀察讀取模型」或「流式投影」或「連續查詢」或任何您想要調用它們的查詢結果（例如，我有多少條未讀消息）發送到用戶每當更新。

[*]有些像IIS這樣的容器使得HTTP調用非常昂貴，您被迫進入WebSocket以實現可接受的延遲（即< 1ms）。但是，這在變化。