Node.js、Socket.IO、Express：应用程序逻辑应该在套接字处理程序还是 REST api 中？答案

【问题标题】：Node.js, Socket.IO, Express: Should app logic be in socket handlers or REST api?Node.js、Socket.IO、Express：应用程序逻辑应该在套接字处理程序还是 REST api 中？
【发布时间】：2018-07-20 15:33:20
【问题描述】：

我正在计划一个重要的实时聊天平台。该应用程序有几种类型的资源：用户、组、频道、消息。大约有 20 种类型的实时事件与这些资源有关：例如，提交消息、用户连接或断开连接、用户加入群组、版主将用户踢出群组等......

总的来说，我看到了组织所有这些复杂性的两条途径。

首先是构建一个 REST API 来管理资源。例如，要发送消息，请 POST 到 /api/v1/messages。或者，要将用户从组中踢出，请发布到/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-only 方法的优势：

更易于分层组织，更模块化
更容易测试
更加健壮和优雅
使用中间件实现更简单的身份验证

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

性能稍差 (source)
既然无论如何都需要打开套接字连接，为什么不将它用于所有事情呢？
在客户端管理起来有点困难。

感谢阅读！

【问题讨论】：

标签： node.js rest express socket.io api-design

【解决方案1】：

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

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

“STARTS_TYPING”、“STOPS_TYPING”、“SEND_MESSAGE”、“RECIVE_MESSAGE”……

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

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

所以最好基于 sockets[socket.io 或 web 集群]构建一切。

【讨论】：

【解决方案2】：

这是我找到的解决此问题的解决方案。

我的问题中的关键错误是我认为 rest API 和 websocket 是互斥的，因为我打算将业务和数据库逻辑直接集成到 express 路由和 socket.io 处理程序中。因此，在 socket.io 和 http 之间进行选择很重要，因为它会影响我的应用程序的核心业务逻辑。

相反，使用哪种传输方式并不重要。业务逻辑必须独立于传输逻辑，在其自己的模块中。

为此，我开发了一个服务层来处理 CRUD 任务，以及更具体的任务，例如身份验证。然后，这个服务层可以很容易地从 express 路由和 socket.io 处理程序中的一个或两个中使用。

最后，这种架构让我不能轻易地在传输技术之间切换。

【讨论】：