SPA應該使用Ajax還是socket.io？

Question

瀏覽GitHub存儲庫，我經常看到使用Ajax而不是socket.io的SPA實現。令我感到驚訝的是，我猜socket.io實現應該更快（所以你不必每次更改路由都打開連接），因此可以提供更好的用戶體驗。或者我錯過了什麼？基於Ajax的SPA有什麼優勢？

Answer 1

這個決定完全取決於你的要求，沒有應該。它甚至不是「一個......或」的決定，在某些情況下，使用混合方法可能是一個好主意。

基於Ajax的SPA有什麼優勢嗎？

的幾點思考：

• 可重用性：正如你可能知道，socket.io不只是周圍的WebSockets的包裝。事實上，它使用與其他WebSocket實現不兼容的自定義協議 - 您的（網絡）客戶端必須支持socket.io。另一方面，當使用Ajax時，你可以創建一個可重用的REST接口，它可以被不同類型的應用程序同時消費，例如，由您的SPA和另外一個本地移動應用程序。
• 客戶端和服務器端的複雜性：用於構建SPA的大多數Javascript框架爲Ajax相關通信提供了極好的開箱即用支持，而Ajax調用只是普通的舊HTTP請求，每個Web服務器都在那裏。
• 性能：正如您所指出的那樣，在每個請求上都不需要socket.io來建立新的連接。但事實是，使用HTTP時也不一定如此。現代瀏覽器利用（或多或少）智能連接管理，如果請求之間的空閒時間不太長，可能會對後續請求使用相同的連接。如果你有很多併發用戶，這比使用socket.io更節省資源，即使沒有流量，它也可以長時間連接。

Answer 2

添加到絕對正確的答案@alapeno發佈，這裏沒有「最佳實踐」。這是你的使用案例。

使用Websockets（其中socket.io只是一個實現，恕我直言，有更好的）允許你有雙向通信之間的客戶端和服務器，其中服務器可以發起通信，只要套接字已啓動。

另一方面，Ajax要求客戶端每次啓動通信。

兩者都有優點和缺點。

的WebSockets

一些優點

• 低開銷用於發送和接收數據
• 可以取代 「傳統的Ajax」 使用像SwaggerSockets
• 服務器的消息格式可以把事件給客戶

個

一些缺點

• 服務器上的低效利用內存。如果您有大量套接字連接，則服務器進程使用的RAM數量將迅速增加。一些Websocket庫在內存管理上比其他的更差。 （即你將需要更多的服務器/資源）
• 沒有「標準化」的方式來記錄發送和接收數據的格式。您需要明確如何通過已建立的套接字調用服務器上的函數，或者探索使用SwaggerSockets之類的東西。
• 如果第三方需要使用您的API，Websockets可能是數據交換的一個特別糟糕的選擇，因爲大多數應用程序可以輕鬆地調用REST API，但使用基於套接字的方法設置較少。

阿賈克斯

一些優點在服務器上

• 較低的存儲需求。由於連接不是「永久」持久的，並且是爲了拉取而非推送而設計的，所以與使用Websockets相比，您可能會處理更多的客戶端。
• 標準化文檔格式。使用Swagger，Slate等爲您的API創建出色的可讀文檔，這對您未來的自我以及任何潛在的第三方都很有用。
• Ajax通常被大多數Web開發人員很好的理解。
• 減整體複雜

一些缺點 - 更多的開銷。對於每一個請求，你都會有不同的頭文件，TCP開銷等，儘管這不是一個真正的問題。正如@alapeno所說，現代瀏覽器在連接管理方面非常智能。 - 無推送通知。如果你想知道服務器上發生了什麼事情，你必須問。 （服務器發送的事件在瀏覽器支持方面仍然處於初級階段，儘管這對於推送來說最終會是一個不錯的選擇。）

我確定每個類別都可以添加更多的點，但那些點是我在選擇時經歷的許多事情。

不同用例的一個很好的例子是Stripe vs. Slack。

條紋有一個非常好的REST API，因爲它們直接針對事務操作。他們沒有在外部使用Websockets，因爲它對他們的模型沒有意義。

另一方面，Slack是關於實時通信。他們廣泛地使用Websockets發送和接收消息，因爲用戶在發送數據後立即收到數據是非常必要的。當然，Slack也有一個REST API，所以在單一服務中使用它們顯然是有意義的。