I know real-time chatting app definitely needs reverse AJAX.But how about other applications that real-time function is not so important?
Say there is a notification function like on Stackoverflow. When people answer your question you get a notification. Probably this is not so important for user to get notified immediately when there is a new answer.
Does this kind of function needs a reverse AJAX? Or it is good enough to set it as a basic AJAX that request the new notification every 60 seconds? Does the basic AJAX consume a lot of server resources? How to choose between them?
I think generally there can be 3 use cases:
You want to display every single update to the user as soon as possible. If so, definitely go with Long Polling. Example: a chat.
You don't need real time notifications and big delays are not a problem. In this case, Traditional Polling with a big interval is good enough for you. Example: updating some statistics in user profile.
The third case is something in between - you don't need real-time updates, but still don't want a big delay.
a. If your data changes frequently, but you don't need to report every single change to users, then Traditional Polling might be better, because it wouldn't send unnecessary updates.
b. If the data rarely changes and you prefer to notify about every change, then again Long Polling might be better, because it won't send the same data again and again.
As user489041 noted, you also need to take into consideration your sever environment. Long Polling keeps a TCP connection open the whole time a user is on the page which has your Long Polling AJAX script. It can become a problem if you have tens of thousands users and only one server. Even if you have less than 10000 users, you need to make sure that your application server is configured to handle that many simultaneous connections. For example, Tomcat in default configuration can't handle more than 200 simultaneous connections.