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 通知客户端。

另一种选择是根本不使用 REST 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 的方法的优点：

• 更容易分层组织，更模块化

• 更容易测试

• 更坚固、更优雅

• 使用中间件更简单的身份验证实现

REST API 相对于仅使用 socket.io 的方法的缺点：

• 性能稍差（来源）

• 既然套接字连接无论如何都需要打开，为什么不将它用于所有事情呢？

• 在客户端管理起来稍微困难一些。

---

谢谢阅读 ！

Answer 1

这可以使用套接字来实现。

为什么是因为聊天应用程序将有数十个操作，例如..

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

使用 REST API 来容纳所有这些功能将生成一个缺乏性能的复杂系统。

此外，socket.io 中的房间概念简化了有关群聊实现的许多令人头痛的问题。

因此最好基于套接字构建所有内容[socket.io 或 web cluster]。