Real-time web browser apps

We believe we are seeing an emerging real-time economy, that is demanding real-time web applications. The best way to build these applications is a fairly proven concept of what is called Event Driven Architecture, and works fairly well in traditional server and client computer environments.

But due to the nature of the HTTP protocol, Javascript and HTML standard, creating a distributed Event Driven Architecture that is seamlessly integrated with a web-browser client-side has a number of challenges.

Recently we started building a generic solution to solve this, and come around some of the common problems that arise.


Right now in more than one application that we are building at this time, we have a need to provide a web-based user interface that is as responsive as a native app of events on the server-side. Many applications solve this with polling, but that has two major drawbacks:

  1. It’s not really real-time, as there is a polling intervall (lower intervalls will make this go away).
  2. It’s very wasteful on resources, both on the server side, networks and the client web browser, as the constant polling creates new requests and round-trips to the server even if there is no new events. Trying to mitigate no 1, will just increase the overhead.

So what can we do to get around this?

We started developing a Remote Messaging framework that consists of a Java back-end (running in our favourite web framework Play!), and a Javascript client framework, that allows Javascript code to subscribe to message (or event) queues in a real-time pub-sub model.

Early tests have worked very well for us, and is not dependent on HTML 5 WebSockets, here is a short example of how the code might look like on the client and server side.

Client-side code can pretty much do this:

RemoteMessagingFramework.subscribe( ‘tweet-xxxx’, function(msg) { … } );

On the server-side, a back-end job listening (and filtering) the Twitter real-time feed might do:

Message msg = new Message( payloadObject );

RemoteMessagingFramework.publish( “tweet-xxxx”, msg );

And that is it!

When the server publish a message, the client will receive and the provided event-handler function (in client-side Javascript) in the browser will be called to process the msg in real-time.

Status of the project

The framework is in it’s infancy and fairly basic, and still needs more testing, bug fixing, and work, but it looks promising, we are hoping to get this to a mature level to be included in our current projects, and the if we reach appropriate critical mass and stability we will do our best to open-source the framework. No promises yet though!

We will also look further into how we can build a HTML 5 agnostic solution, that falls-back to older browsers, but will use HTML 5 and Web Sockets if available. Other options that we might explore is integrating this to a Messaging Queuing back-end (JMS).

Thoughts, ideas? Would you be interested in the framework and use it for your applications? What typical applications would you be interested in building using this?

From the BootstrapWorks blog.