Node.js、Socket.IO、Express：應用程序邏輯應該在套接字處理程序中還是在 REST api 中？

Question

我正在計划一個重要的實時聊天平台。 該應用程序具有多種類型的資源：用戶、組、頻道、消息。 大約有 20 種類型的實時事件與這些資源有關：例如，提交消息、用戶連接或斷開連接、用戶加入群組、版主將用戶踢出群組等......

總的來說，我看到了兩種組織所有這些復雜性的方法。

首先是構建一個 REST API 來管理資源。 例如，要發送消息，POST 到/api/v1/messages 。 或者，要將用戶從組中踢出，POST 到/api/v1/group/:group_id/kick/ 。 然后，從 Express 路由處理程序中，使用更新的數據調用io.emit （可通過 res.locals 訪問）以通知所有相關客戶端。 在這種情況下，客戶端通過 HTTP 與服務器通信，服務器通過 socket.io 通知客戶端。

另一種選擇是根本沒有休息 API，並通過 socket.IO 處理所有事件。 例如，要發送消息，請發出SEND_MESSAGE事件。 或者，要踢用戶，請發出KICK_USER事件。 然后，從 socket.io 事件處理程序中，使用更新的數據調用io.emit以通知所有客戶端。

另一種選擇是讓某些操作由 REST API 處理，其他操作由 socket.IO 處理。 例如，要獲取所有消息，請GET api/v1/channel/:id/messages 。 但是要發布消息， SEND_MESSAGE發送到套接字。

哪個是最合適的選擇？ 如何確定哪些操作需要通過 API 發送，哪些需要通過 socket.io 發送？ 這種類型的應用程序最好不要有 REST API 嗎？

---

到目前為止我的一些想法，沒有定論：

REST API 相對於 socket.io-only 方法的優點：

• 更易於分層組織，更模塊化

• 更容易測試

• 更加堅固和優雅

• 使用中間件實現更簡單的身份驗證

REST API 相對於 socket.io-only 方法的缺點：

• 性能稍差（ 來源）

• 既然套接字連接無論如何都需要打開，為什么不把它用於所有事情呢？

• 在客戶端稍微難以管理。

---

謝謝閱讀 ！

Answer 1

這可以使用套接字來實現。

為什么是因為聊天應用程序將有幾十個動作，比如..

“STARTS_TYPING”、“STOPS_TYPING”、“SEND_MESSAGE”、“RECIVE_MESSAGE”、...

使用 rest api 來適應所有這些功能將生成一個缺乏性能的復雜系統。

socket.io 中房間的概念也簡化了很多關於群聊實現的麻煩。

所以最好基於sockets[socket.io or web cluster]構建一切。

Answer 2

這是我找到的解決此問題的解決方案。

我的問題中的關鍵錯誤是我認為 rest API 和 websockets 是相互排斥的，因為我打算直接在 express 路由和 socket.io 處理程序中集成業務和數據庫邏輯。 因此，在 socket.io 和 http 之間進行選擇很重要，因為它會影響我的應用程序的核心業務邏輯。

相反，使用哪種傳輸方式並不重要。 業務邏輯必須獨立於傳輸邏輯，在其自己的模塊中。

為此，我開發了一個服務層來處理 CRUD 任務，但也處理更具體的任務，例如身份驗證。 然后，這個服務層可以很容易地從 express 路由和 socket.io 處理程序中的一個或兩個中使用。

最后，這種架構讓我不能輕易地在傳輸技術之間切換。