Ajax vs Socket.io
I am developing a web app and I was wondering which method should be suitable for my project.
Basically what I want to display to the users are some notifications which are taken from requests to other servers. My node.js app gets all the info and then it spread out to the users, saving a copy into my MongoDB.
The idea is quite simple but reading about methods I found these two techniques:
Ajax : Client side would be checking all time if there is new content on the server. This would be done by using a jquery ajax get to my server API (every 30/60 seconds).
Socket.io : The client connects once, and then a permanent TCP connection is maintained (more realtime).
Now I have explained the situation, I have the following questions :
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 ?
Would the socket.io be a problem for mobile devices ? bandwith and performance. The response of the server is always info in JSON format.
I read that now.js could be used for this but it seems the project is no longer supported, so not sure if using it would be a good idea.
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 ?
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.
Any alternative suggested ?
I hope this could clear my mind and others who are in the same situation :) Thanks
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.