Facebook-f Google
Contact us
back to all

Real time application development technology solutions

As a veteran web developer, I have seen huge changes in client requirements and the way we build websites.

In the early days, web development was just about creating static documents accessible online, but quickly we needed a way to link these requests into a “session”, and this allowed for user authentication and customisation of user experience.

We built large complex online applications that required user-initiated interaction where a request was made to the server and content served to the user. Many developers still use this approach and most websites online today probably fall into this category. To check for changes the user has to refresh.

Then technological developments allowed for asynchronous requests and we could start to build in some degree of continuity between user-initiated requests. This became increasingly common with the increasing popularity of jQuery and the use of AJAX (asynchronous JavaScript and XML).

Not only can user interaction be handled asynchronously but the app can periodically check the server for data changes and display changes in the UI. This gives the website some degree of real-time, but with a latency of whatever time period, the checks are done.

For many developers, this is still the “state of the art”, and when you take into account institutional and legacy limitations this is often the case.

At the leading edge, however, we can now build JavaScript front end and back end with Socket.IO to create the bidirectional event-based communication between the browser and server. The app “pushes” new data to the front end rather than periodically checking for new data.

As a developer, it’s great when there are no limitations on the choice of technologies we use to build the application. Unfortunately, this is rarely the case and we may have no choice but to use a LAMP (Linux Apache MySQL PHP) back end. In this case, we have two main choices for developing a real-time application:

  1. A “long polling” approach where requests sleep on the server until new data or changes are found, or until the timeout occurs (or approaches)
  2. A “heartbeat” approach where regular requests are made to check for new data or changes, eg every 20 seconds

There are pros and cons to each approach. A heartbeat involves much more network traffic, while long polling can use a lot of server resources as each connection to the server commits resources.

PHP long polling

The general approach is to check for new data and if none then sleep for a period of time before checking again and return data if found.

//check for new data, if returns false then sleep for 5 seconds and try again
while(!$data = has_event_happened()) {
   sleep(5);
}
echo json_encode($data);

Normally has_event_happened() would be a database query to check for new data.

The front end implementation could be equally simple using jQuery:

function doPoll() {
   $.get(""poll.php"", {}, function(result) {
      //do something with your event
      //run the poll again as soon as the response comes back
      doPoll();
   }, 'json'); 
}

$(document).ready(function() {
    $.ajaxSetup({
       //set global AJAX timeout to close to your desired php timeout setting, eg 5 mins
       timeout: 1000*60*5
    });
    //do the first poll
    doPoll();
});

In this example, a new request is made every 5 mins (if no new data sooner) and new data is checked on the server every 5 seconds. In theory, the latency is approximately 5 seconds since new data is sent to the front end within 5 seconds of a change.

That’s about as simple as it gets so clearly you’d need to build in appropriate event management and error logging and reporting.

If you’re not careful Apache will quickly tie up all the “worker threads” and leave it unable to respond to other requests. In many cases, this will rule out long polling as an option but with a bit of server setup tweaking, it can be a viable option.

Heartbeat

This approach is very similar to the long poll except that the sleep occurs on the client-side rather than server-side. With long polling, new data will be sent to the front end once detected server-side. With the heartbeat approach, the front end waits between requests and the back end returns the result immediately as requested.

//check for new data
$data = check_for_event();
//return what was found
echo json_encode($data);

The front end using jQuery uses a timeout to wait 20 seconds between requests.

function doPoll() {
   //set timeout to 20 seconds
   setTimeout( function() {
      $.get(""poll.php"", {}, function(result) {
          //do something with your event
          //call the poll function again as soon as the response comes back
          doPoll();
      }, 'json');
   }, 200000);
}
$(document).ready(function() {
    //do the first poll
    doPoll();
});

Again this is just about as simple an implementation as you can get. The latency of this example would be approximately 20 seconds.

Regardless of which approach you use you should make sure to do load testing and calculations to ensure your server resources are sufficient.

I generally use a PHP framework that allows AJAX requests to be as lightweight as possible to further reduce server load. AJAX requests don’t need any templating so I don’t instantiate a templating engine (such as Smarty, Mustache, Twig, etc).

Some More Cool Projects