1

I'm wondering about the pros and cons of handling the auto-updating of a <div> on server vs. client side. I'm using Apache with PHP but was just thinking of faking a push notification in Javascript like this:

setInterval(queryDatabaseForUnreadMessages, 60000);

function queryDatabaseForUnreadMessages(){
   $.ajax({
       url: "/messages/queryDatabaseForUnreadMessages",
       success:function(data){
          $('div#littleRedCircle').html(data);
       }
   });
}

I'd just like to set up a notification like Stackoverflow has done (little red circle with a number in it) to let people know they've received a new message if one exists. Is that simple AJAX/setInterval combo a bad idea?

tim peterson
  • 23,653
  • 59
  • 177
  • 299
  • 1
    Push notifications are realtime but pull => ajax poll is near realtime :P It will be hard for you to decide on the poll interval in the second case – Tamil Jun 28 '12 at 14:50
  • @Tamil thanks, why is it hard? is every minute such a bad idea? – tim peterson Jun 28 '12 at 14:53
  • I don't see anything wrong with it, but there is also server signaling (long-polling). In c# we have SignalR but I don't know what's available for PHP. – Thinking Sites Jun 28 '12 at 14:54
  • thanks, i'm investigating PHP solutions now... – tim peterson Jun 28 '12 at 14:59
  • Possible duplicate of http://stackoverflow.com/questions/4642598/short-polling-vs-long-polling-for-real-time-web-applications – Tamil Jun 28 '12 at 14:59
  • And nowadays you can even use websockets (with fallback to long polling or these pull requests). – Styxxy Jun 28 '12 at 15:02
  • 1
    Look into using websockets with Python/Tornado and SockJS. Runs in a separate application layer than your PHP app, but very easy to setup with no prior knowledge of Python. Run it on the same server with HAProxy or Varnish – nathancahill Jun 28 '12 at 15:05
  • @Tamil thanks for the link, checking it out... – tim peterson Jun 28 '12 at 15:11
  • @timpeterson have posted my suggestions though ;) – Tamil Jun 28 '12 at 15:26

2 Answers2

3

The only con to server push is the implementation cost (time, money)

Server push is the way to go, because

  1. Realtime notifications are better from the user's perspective
  2. It has predictable costs (so it's scalable)
  3. Reduces bandwidth consumption
  4. Saves server load

It depends on your specific requirements which one to choose, because the implementation cost of the server side push is not trivial, as it's not really a matter of a single PHP script, but requires deep server integration (maybe you'll have to install another HTTP server altogether) and involves other pieces of software (message queues?) which are not typically built with PHP

Raffaele
  • 20,627
  • 6
  • 47
  • 86
  • hi @Raffaele, thanks, I'm just an inexperienced one-man operation so the time,money is a real issue at this point. I'd like to implement a server push for the 4 reasons you mention but it may be to challenging for me at this point? – tim peterson Jun 28 '12 at 15:05
  • No, it has not to be :) there exist quite a few packages to do this things, which are both free and easy to set up (well, *how easily* really depends on your skills), but it can get expensive if you want to put it online, while for experimenting on local network it's ok – Raffaele Jun 28 '12 at 15:10
  • hi @Raffaele, I'm now experimenting with Push notifications. I've got http://Pusher.com 's service running on my site. Unfortunately, they only support 20 connections under their free service. What websites only need 20 simultaneous connections? That seems a really small number. Can you say what Push notification libraries/packages you've found that were good? I'm thinking about Amazon SNS/SQS but code examples for this particular AWS service are particularly non-existent so I'm having trouble putting the full picture in my head of how to use this. Thoughts? – tim peterson Jul 24 '12 at 08:16
  • -@Raffaele, I've also seen http://socket.io but like Amazon SNS/SQS i'm having trouble connecting the dots in their documentation... – tim peterson Jul 24 '12 at 08:20
  • [Socket.IO](http://socket.io/#how-to-use) is perfectly fine. Note that it requires its own HTTP server, so -again- it's ok for local testing, but if you want to put it online, a shared PHP host will not be enough – Raffaele Jul 24 '12 at 09:06
  • I'm happy to implement a separate server dedicated to the push notifications. Seems like the extra $30/month would be worth it. The main thing I don't understand is how for the Node and PHP servers talk. I assume its via a URL? Also, are you implementing push notifications on any of your projects? If so, may I ask what libraries you are using? – tim peterson Jul 24 '12 at 09:22
  • How they communicate depends on what your application does (just wondering, what would you use URLs for?). You could describe it here, but you'd better asking another question – Raffaele Jul 24 '12 at 10:43
2

From IETF DOC

Long Polling in Contrast with Pull

What are the issues with Long Polling though? From DOC

  1. Header Overhead
  2. Maximal Latency
  3. Connection Establishment
  4. Allocated Resources
  5. Graceful Degradation
  6. Timeouts & Caching

As I mentioned in my comment

Long Polling is realtime whereas Pull is near realtime [determined by the poll interval]

Pull takes the client's bandwidth for granted :P

As mentioned in the DOC both the techniques makes use of persistence connection of HTTP 1.1 well.

Pull is easy to implement and well supported across browsers. While Push lacks that but libraries are there to rescue ;).

Community
  • 1
  • 1
Tamil
  • 5,260
  • 9
  • 40
  • 61