Node.js、Socket.IO、Express : Should app logic be in socket handlers or REST api?

Question

我正在计划一个重要的实时聊天平台。该应用程序有几种类型的资源:用户、组、 channel 、消息。大约有 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到 socket 。

哪个是最合适的选择？如何确定哪些操作需要通过 API 发送，哪些需要通过 socket.io 发送？最好不要为这种类型的应用程序提供 REST API？

到目前为止我的一些想法，没有结论:

REST API 相对于 socket.io-only 方法的优势:

更易于分层组织，更模块化

更容易测试

更健壮、更优雅

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

REST API 相对于 socket.io-only 方法的缺点:

性能稍差(source)

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

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

谢谢阅读 !

Answer 1

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

为什么因为一个聊天应用程序会有几十个 Action ，比如..

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

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

此外，socket.io 中的房间概念简化了关于群聊实现的很多麻烦。

因此，最好基于 sockets[socket.io 或 web cluster] 构建一切。