SPA：仅使用 websockets。为什么不？答案

【问题标题】：SPA: using websockets only. Why not?SPA：仅使用 websockets。为什么不？
【发布时间】：2014-07-24 06:12:46
【问题描述】：

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

我可以想象，如果网络连接像在移动设备上那样糟糕，使用 websockets 可能不是最好的主意，但在合理的网络连接情况下，这可能会很好地工作。

我发现了这个相关的问题，但它是从 2011 年开始的，似乎有点过时了： websocket api to replace rest api?

【问题讨论】：

在分布式事件源 CQRS + Redux 应用程序的上下文中考虑相同。基本上，从我想要的任何内容中提供静态内容，并仅通过双向 websocket 交换纯动作/事件。目前正在寻找参数，如果我没有外部 API 使用者，为什么我还需要维护 REST API。
@Dzintars 我个人的建议是：如果您确实需要通过网络获取数据，请使用大多数网络使用的方式。如果您有充分的理由使用其他东西（例如 WebSockets），那么这样做可能是有意义的。但是，您很有可能还会注册一些边缘案例、浏览器错误以及可能的一些变通方法来修复一些奇怪的事情。如果你的充分理由仍然更重要，那就去吧。至于我：我目前正在花费一些时间来最终摆脱 WebSockets 作为主要通信方式。

标签： websocket single-page-application

【解决方案1】：

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

问题可能是缺少基于持久连接的框架/工具。多年来，大多数框架（前端和后端）都是围绕请求/响应模型设计和构建的。方法转变可能并不容易接受。

【讨论】：

是的。仅通过 WebSocket 与后端进行 SPA 对话是一种可行的方法。您可能对wamp.ws 感兴趣，它提供了基于 WebSocket 的常用抽象：远程过程调用（RPC，类似于 Ajax 需求）加上发布和订阅。在一个基于 WebSocket 的子协议中。披露：我是 WAMP 的原作者。
对，我找到了 WAMP，我认为它很棒，但我们决定设计自己的协议。我们的应用程序作为 FSM 工作，因此没有显式订阅，例如，服务器根据您的状态决定向您发送什么。
什么是 FSM？ @vtortola
FSM 是有限状态机的常用缩写。我想我听说 FSM 比有限状态机更频繁。

【解决方案2】：

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

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

【讨论】：

Sec-WebSocket-Extensions: deflate-frame 不是用来启用压缩的吗？ tools.ietf.org/html/rfc7692
是的，我对此的了解可能有点过时了。我试图找到有关当前浏览器支持的更多信息，但在快速搜索后无法找到。如果您找到有关这方面的好信息，如果您也可以在此处添加，我将不胜感激。
我认为设置 websocket 服务器需要额外的学习曲线，并且 websocket 不内置重新连接（使用 socket.io 的原因之一）
是的，有很多原因。我只想说：除非有很好的理由，否则不要这样做。或者：不要仅仅因为你可以这样做:)