Clever Geek Handbook

Socket.io vs AJAX Use Cases

Background: I am creating a web application using NodeJS + Express. Most of the communication between client and server is REST calls (GET and POST). I would normally use AJAX XMLHttpRequest as stated at https://developers.google.com/appengine/articles/rpc . And I don't seem to understand how to make my RESTful service also usable for Socket.io.

My questions

  •  
  • In what scenarios should I use Socket.io over AJAX RPC?  
  • Is there a direct way to make them work together. At least for REST style for Expressjs style.  
  • Do I have any real benefit of using socket.io (if using websockets - TCP layer) for realtime web applications. Like a tinyurl site (where users submit requests and the server responds and forgets).

And I was thinking about a complex but pointless idea. What if I use RESTful for client requests and close the server side connection and execute socket.emit()

.

Thanks in advance.

+3


source to share


2 answers


The main problem is that WebSockets are not request-response oriented like HTTP. Remember that REST and HTTP are interchangeable, keep in mind that REST is a methodology for designing and modeling your HTTP routes.

Your questions, 1. Socket.io would be a good scenario if you don't need a request / response format. For example, if you were building a multiplayer game in which anyone who could click on more won buttons, you were sending every click from every user to the server, without needing a response from the server where they were logging every click. As long as the WebSocket connection is open, you can assume that the message is being sent to the server. Another use case is when you need a server to communicate with a client sporadically. An analytics page would be a good use case for WebSockets as there is no single pattern for when data needs to be on the client, this can happen at any time.



  • A WebSocket connection is an HTTP GET request with a special header that asks the server upgrade

    to connect to the WebSocket. Distinguishing between different events and messages on a WebSocket connection depends on your application logic and will probably not match URIs and REST style methods (otherwise you would use an HTTP request / response in the sense).

  • Not.

Not sure what you mean in the last bit.

+4


source


I'll just go over more about when you want to use Socket.IO and leave Tj's detailed explanation there.

Typically, you choose Socket.IO when performance and / or latency is a major concern and you have a site that often includes polling users for data. AJAX or long polling is much easier to implement, however it can have serious performance issues in high load situations. By high load I mean like Facebook. Imagine that millions of people are downloading their feed, and every minute every user is requesting new data from the server. It might take some serious hardware and software to work well. With Socket.IO, each user can instead connect and just wait indefinitely for new data from the server as it arrives, resulting in significantly less overall server traffic.



Also, if you have a real-time application, Socket.IO will allow for a much better user experience while maintaining a reasonable server load. A common example is chat. You really don't want to constantly poll the server for new messages. It would be much better if the server broadcasts new messages as they are received. While you can do this with long polling, it can be quite expensive in terms of server resources.

+1


source






More articles:


All Articles