How do clients detect if a page should be updated?

Question

I have a table in a page that shows summary data.
These data come from a summary database table. I need to refresh this table shown in the page if the underlying table gets updated.
The way that I know is to reload the page every X seconds.
But what I am interested in is to update the table whenever the table is actually updated.
What is the standard solution for this? The only approach I was able to think was to add some extra column to the table to have the row ids that have been updated and somehow "poll" on this column every X seconds. I think it could work but it seems horrible solution and I was wondering what would be the standard approach to this (I assume common) problem.

Update:
Just to add more content. My question is not so generic. I have only 1 specific part of the code that updates the table and the update is under my complete control. It is not like a table that gets updated by multiple sources

Answer 1

Communication System

You have multiple ways to create a sort of dynamic page that auto updates (i.e. like Facebook).

1. Basic. The most basic method is, like you said, polling the server every X seconds (having a JavaScript infinite $.ajax({}); loop that is called each X seconds) to see if there are new things on the server. This is a valid solution, and it has been used in the past.

2. Push. A second way of doing this and is quite used also, is long polling or push. If you are using an asynchronous framework on the backend (i.e. Node.js, Tornado, Twisted etc.) you can very easily use this solution since it has almost no performance cost. With other back end frameworks like PHP or Django, this is not a good way of doing it since you create a process per each request that stays open until something is updated or the time out for the Http connection is being reached (people put most of the time, from what I saw, a 30s timer on the long polling).

3. Sockets. This is the newest and most unsupported way of doing this. Not all browsers have yet access to WebSockets. As before an asynchronous framework is better for this approach.

If you are having a CGI base back en framework (this implies WCGI, FastCGI, etc) like Django , PHP, Flask, etc. then you are better taking the first approach, which is the most basic one. Taking any other is very resource costly for your servers. If you have an async back end, then either the 2nd or 3rd approach are ok. I must say that the web sockets approach is a bit harder to get into, program correctly and support the framework.

Database System

After you chose what you want to use as a communication system, your database design need to reflect the new query types you need to do.
Let's say the user wants to see all the new changes since he loaded the page.

• A simple way of doing it would be to have a date on each row, which is the time of the last change. Query for all rows that changed since last query time.

• A more complex way of doing it is to implement a full notification system. For each change or new row, a new notification about it will be added. You can do a relation between a user and notifications to know if he has already seen it, and have a job scheduled each 24h to delete old relations. But very soon this all becomes bloated. I prefer using a NoSQL database (JSON one like CouchDB) for the notification system. You can easily change the structure of the documents and create specific views for all notifications. It is more lenient to work with than a relational database. If you want to know if your data has changed after user loaded the page, all you have to do is query the type of notification (what data/table you are observing for changes) and get the ones with a creation date newer than the last queried time and also non-viewed. Since your table always reflects the last state, on page load you query the table and afterwards you only query for changes or here called notifications.

My Personal Take

If you are having a CGI backend, for a complete notifications system you will require a specific back end structure added on top of yours for either long polling or sockets. Don't forget your client needs to also have logic on how to react to the new server handlers. For quick results, if your job specifies this, you are better suited with just a script in your page that reloads the page each 1 minute or so.

If you are already using an asynchronous framework, you can easily add the notifications functionality but will require hard work on the database, especially if the notifications are in a relational one. If you decide to add a new database specifically for this, it requires also a lot of app logic on your back end plus the training for it.

Hope I helped, cheers!

Answer 2

There are a lot of different approaches to solving a problem like this. The best and most efficient solutions will involve some help from your server to know when/what has changed. Here are some ideas:

1. Use a websocket connection to your server so your server can notify when the back-end data has changed and the client can then request fresh data.

2. Deliver some sort of "last transaction id" with the original page and then use an ajax call on a polling interval to ask the server if the data has changed since this last transaction id. If so, request the new data. If not, nothing to do. This keeps you from getting the data over and over when nothing has actually changed.

3. Alternatives to a websocket are long polling of http push which can also be used (particular in clients that don't support websockets) to allow the server to notify the client when there is new data.

Answer 3

This is the premise of WebSockets (http://socket.io for a shim). You'll need (as already mentioned) a server (such as Node.JS) to support the WebSocket functionality -- most modern web browsers support this API on the client-side.

Web Sockets API (http://www.w3.org/TR/2012/CR-websockets-20120920/) allows the browser to continuously communicate data to a server (and vice-versa).

If a database record is updated, you can set a trigger to communicate this data back to the client. Look at comment board systems (exactly like the one we're using here on StackOverflow) for examples -- since there's an enormous amount of information already available on the web, I don't believe it necessary to go into great detail here.

Further reading and tools:

• http://www.html5rocks.com/en/tutorials/websockets/basics/
• https://developer.mozilla.org/en-US/docs/WebSockets
• http://pusher.com/

As mentioned by others, you may do polling through setInterval (preferred) or setTimeout methods using AJAX. Don't forget to create a variable to store the ID of the set[Fn] in case you (or the user) wish(es) to cancel it:

var pollID = window.setInterval(function poller(){ getAjaxData(); }, 2000);
if (noUpdate) window.clearInterval(pollID);

Answer 4

Polling is the easiest way. It will look like this:

(function poll() {
  $.ajax('/myTableData', {
    success: function(data) {
        updateTable(data);
    },
    complete: function() {
       setTimeout(poll, 8000); //every eight seconds
    }
  });
})();

And then you'll add the endpoint /myTableData to your server.

Google Docs, which supports real-time collaboration, polls at the time of this writing. However, it is more sophisticated in that the poll are "long": they last as long as it takes until new data arrives, or certain amount of time passes (e.g. 40 seconds), whichever comes first. That reduces the amount of polling.

Alternatively, you could look into websockets which are supported in modern browsers (IE 10+).