SPA应该使用Ajax还是socket.io？
浏览GitHub仓库，我经常看到使用Ajax而不是socket.io的SPA实现。 这令我感到惊讶，因为我猜socket.io实现应该更快（所以你不必每次改变路由都打开连接），因此提供更好的用户体验。 还是我错过了什么？ 基于Ajax的SPA有什么优势？
这个决定完全取决于你的要求，没有应该 。 这甚至不是一个“或者”或“是”的决定，在某些情况下，使用混合方法可能是一个好主意。
基于Ajax的SPA有什么优势？
一些想法：
- 可重用性：正如你可能知道的，socket.io不仅仅是WebSockets的包装。 实际上，它使用与其他WebSocket实现不兼容的自定义协议 – 您的（web）客户端必须支持socket.io。 另一方面，当使用Ajax时，您可以创build一个可重复使用的REST接口，同时消费不同types的应用程序，例如，通过SPA以及本地移动应用程序。
- 客户端和服务器端的复杂性：用于构buildSPA的大多数Javascript框架为Ajax相关的通信提供了极好的开箱即用支持，Ajax调用只是普通的旧HTTP请求，每个Web服务器都可以理解在那里。
- 性能：正如你所指出的，socket.io不需要在每个请求上build立一个新的连接。 但事实是，使用HTTP时也不一定如此。 现代浏览器利用（或多或less的）智能连接pipe理，如果请求之间的空闲时间不太长，可以使用相同的连接用于后续请求。 如果你有很多的并发用户，这比使用socket.io更节省资源，即使没有stream量，它也会使连接长时间处于打开状态。
加上@alapeno发布的绝对正确答案，这里没有“最佳做法”。 这是你的用例。
使用Websockets （其中socket.io只是一个实现，恕我直言，有更好的）允许你有双向的客户端和服务器之间的通信，服务器可以启动通信，只要套接字启动。
另一方面，Ajax要求客户端每次启动通信。
两者都有优点和缺点。
的WebSockets
一些优点
- 发送和接收数据的开销很小
- 可以使用像
SwaggerSockets这样的消息格式来replace“传统的Ajax” - 服务器可以将事件推送到客户端
一些缺点
- 服务器上的内存使用效率低下 如果您有大量的套接字连接，则服务器进程使用的RAM数量将迅速增加。 一些Websocket库在内存pipe理上比其他的更差。 （即你将需要更多的服务器/资源）
- 没有“标准化”的方式来logging发送和接收数据的格式。 您需要明确如何通过已build立的套接字调用服务器上的函数，或者探索使用诸如SwaggerSockets之类的东西。
- 如果第三方需要使用您的API，Websockets可能是一个特别糟糕的数据交换select，因为大多数应用程序可以轻松地调用REST API，但是使用基于套接字的方法设置较less。
阿贾克斯
一些优点
- 降低服务器的内存要求 由于连接不是“永久”持久的，而是为了拉而不是推，所以你可以比使用Websocket处理更多的客户端。
- 标准化的文档格式 使用Swagger，Slate等来为您的API创build漂亮可读的文档，这对于您未来的自我以及任何潜在的第三方都是有用的。
- Ajax通常被大多数Web开发人员所理解。
- 整体复杂度较低
一些缺点 – 更多的开销。 对于每一个请求，你都会有不同的头文件，TCP开销等，尽pipe这不是一个真正的问题。 正如@alapeno所说，现代浏览器在连接pipe理方面非常聪明。 – 没有推送通知。 如果你想知道在服务器上发生了什么事情，你必须问。 （服务器发送的事件在浏览器支持方面仍然处于初级阶段，尽pipe这最终将是一个不错的select。）
我确信每个类别都可以添加更多的点，但是这些是我在select时想到的很多东西。
Stripe vs Slack是不同用例的一个很好的例子。
Stripe有一个非常好的REST API，因为它们直接针对事务操作。 他们并没有在外部使用Websockets，因为这对他们的模型没有意义。
另一方面， Slack是关于实时通信的。 他们广泛使用Websockets来发送和接收消息，因为用户在发送数据后立即收到数据是非常必要的。 当然，Slack也有一个REST API，所以在一个单一的服务中使用它们显然是有意义的。