我目前正在尝试在node.js/express 中编写一个restful API 来执行一些经典的CRUD 操作。此外，为了简单起见，当发生创建/更新/删除事件时，我希望能够在 ws 或 socket.io 的帮助下通知（通知系统）此 API 的客户端。此外，我还实现了一个权限系统（受文件系统权限的启发），该系统具有受 API 影响的每个对象的继承，并且每个通知必须处理相同的权限并仅通知授权用户。
总结一下：API REST 使用 Node/express 以及精细的权限系统，并结合用于通知系统的 socket.io。
我的想法和问题如下：
如果您对此有任何想法、良好实践、示例或批评，请随时发表评论。谢谢。
听起来是一个很酷的项目！
将 REST/API 与 Web 套接字结合使用是一个好主意吗？由于我需要为通知系统建立永久的 ws 连接，并且稍后可能需要聊天，因此仅使用 ws 编写 API 是否会更好？
在我看来，REST 端点比 Websocket 更容易编码和处理，所以我认为尽可能保持简单是有意义的。
为了管理 socket.io 部分的权限，其想法是创建临时房间并添加具有适当权限的当前侦听器（来自数据库），然后在广播通知后删除该房间。还有其他选择吗？
我认为每个连接的侦听器只有一个房间并将消息推送到每个房间可能会更简单，但这只是个人喜好。
由于 REST API 不依赖于通知系统，因此实现“即发即忘”功能来创建房间并发出通知但让 REST API 在另一端发送响应是否是一个好主意？为此创建一个新线程是否合适？由于发送通知不会真正占用 CPU 资源，我认为这是一个坏主意......
这听起来很像对您可能不存在的问题进行过早优化。我建议您首先以简单的方式实现它，然后仅在遇到性能问题时才开始优化。分析是你的朋友。
话虽如此，频繁启动新线程通常是一个坏主意，因为创建它的开销不可忽略。您可以考虑使用负责处理通知的工作线程，该线程永久在后台运行并处理来自队列的通知。当应该处理通知时，它会被写入队列，以便后台线程可以处理它。许多 Web 框架还允许启动异步运行的后台任务。
如果您需要扩展到多个进程/服务器，这听起来有点像 Redis 的用例，它提供了可以通过网络访问的队列和发布者/订阅者系统等数据结构。