SPA:仅使用websockets.为什么不?

st-*_*t-h 10 websocket single-page-application

我正在重新设计一个Web应用程序,该应用程序以前已经在服务器端呈现给单页应用程序并开始阅读有关websockets的内容.Web应用程序将使用套接字将新记录和/或消息推送到客户端.我一直在想为什么大多数使用套接字的页面都不能处理它们在套接字上的所有通信.除了websocket之外,大多数时候都有RESTful后端.让客户端通过套接字查询新资源是不是一个坏主意?如果是这样,为什么 - 除了RESTful api可能更容易与其他设备一起使用?

我可以想象,如果网络连接像移动设备那样糟糕,使用websockets可能不是最好的想法,但是这可能应该与网络的合理连接很好地工作.

我发现了这个相关的问题,但它是从2011年开始看起来有点过时了: websocket api取代了rest api?

vto*_*ola 7

不,这不会是一个坏主意。实际上,我在一个应用程序中工作,该应用程序使用 WebSocket 连接进行所有数据交互,Web 服务器仅处理对资源、不同语言、维度下的视图等的请求。

问题可能是缺乏基于持久连接的框架/工具。多年来,大多数框架(前端和后端)都是围绕请求/响应模型设计和构建的。这种方法转变可能没有那么容易接受。

  • 是的。仅通过 WebSocket 与后端进行 SPA 对话是一种可行的方法。您可能对 http://wamp.ws/ 感兴趣,它提供了 WebSocket 上常用的抽象:远程过程调用(RPC,类似于 Ajax 需求)加上发布和订阅。在一个基于 WebSocket 的子协议中。披露:我是 WAMP 的原作者。 (2认同)

st-*_*t-h 5

几年后回到这个问题,我想指出几个方面来说明通过 websockets 进行所有通信确实有其缺点:

  • 没有对压缩的共同支持。您可以轻松地配置您的网络服务器来压缩 http 请求,并且浏览器多年来一直很乐意接受压缩响应,但是对于网络套接字来说,这仍然不是那么容易(即使情况有所改善)
  • 客户端框架通常建立在常用的标准之上,比如rest。您离框架期望越远,可用的插件或功能就越少。
  • 在浏览器中缓存并不那么容易。到目前为止,这已经很长了,进入了离线可用性和 PWA 的领域。
  • 当使用仅由一部分用户使用的技术时,更有可能发现新的错误,或者错误可能需要更长的时间来修复。如果它不是错误,那么拐角处可能会有一个边缘情况。这本身不是问题 - 而是需要注意的问题。如果遇到这些事情,他们通常很容易花一些时间来修复或解决。