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