Many of the generic tradeoffs between webSocket and Ajax are discussed here:
websocket vs rest API for real time data?
Some tradeoff issues for mobile devices are discussed here:
Cordova: Sockets, PushNotifications, or repeatedly polling server?
In a nutshell, if your data is primarily server-driven and then needs to be sent out to clients and you desire fairly good latency for when the clients see the new data, then that is the exact problem that webSockets are good for. webSockets work best in this situation because the client does not need to poll frequently, the server does not need to handle regular polling requests from lots of clients. Instead, each client just sets up the one persistent webSocket communication channel which the server can then send data down upon demand at any time.
Would I not have too many requests with ajax ? imagine I want a check
every minute to the server, if we scale the app to 100 users, it will
give me 100 queries per minute. Would it be “cheaper” in system
resources to have a socket ?
Sockets require very little resources when they are not active so yes, a peristent webSocket is more efficient than lots of clients polling endlessly. This is why webSockets were invented because they are better at solving this particular problem.
Would the socket.io be a problem for mobile devices ? bandwith and
performance. The response of the server is always info in JSON format.
socket.io is not a problem for bandwidth or performance. There are some mobile issues with trying to use webSockets in the background because mobile devices are also trying to do active power management, though a similar issue exists with client polling too.
How is the caching on both methods ? I was considering to create a
cache file for each user and this would be updated by the node.js in
the server side. I guess this could work really well with ajax but
what about socket.io ?
It is unclear what you are asking about caching? In a webSocket implementation, the server gets the data and then just sends it to each user. No server-side caching would generally be needed. In a client Ajax polling implementation, the server would have to store the data somewhere and “wait” for each client to then request the data. There is no “built-in” caching mechanism for either webSocket or Ajax.
Is it true that socket.io is not compatible at all with many browsers
? My app would be more focused to mobile devices and I think this
could make me think about choosing ajax instead.
socket.io is fully compatible with all browsers that have webSockets which is pretty much everything in use today except for IE9 and older. If you use the socket.io library, it will automatically fall back to long polling if webSockets don’t exist. Your mobile issues are likely going to be similar whether you’re doing regular polling or webSocket because the mobile device wants to power manage long running things, but you don’t want to stop polling. I don’t think this is a reason to avoid webSockets/socket.io. socket.io has some really nice auto-reconnect logic whenever it loses the connection which can be really useful.
In the mobile world, I think you’re just going to find that you can’t reliably do real-time notifications in the background without using some sort of native app component that can plug into the native “push” system on the device because that’s the only system that is both battery efficient and fully compatible with power management. A web page is going to be power managed as soon as it is not the foreground task or when the device has been idle.