I previously talked about bringing real-time data to the web using WebSockets. WebSockets make up one piece of the technology stack required to bring real-time data to the web. In this article I will explore the other pieces you need via a working demo I built which you can interact with.

My Live Example

There are two parts to this example and you can play with both of them.

How to Play with the Example

The idea is that you open both applications. You can then make edits to the polygons in the editing application, and instantly view the edits you/anyone else made in the display application without having to refresh. To make it a bit more fun I added a Twitter stream to the display application which shows a live feed of all the edits being made.

Architecture Diagram

Here is an overview of the architecture:

Architecture Diagram

Key Technologies

FME Server

FMEFME Server is at the heart of the architecture.

Node.js

node.jsI used Node.js to create a web server that the FME Server notification server interacted with. Many other people have taken the time to do a full review of Node.js, so I won’t here. However, what I liked about it was that it is extremely lightweight, easy to setup and configure, and best of all you write applications on the server-side in JavaScript. From the reading I’ve done, it also seems it is highly suited to supporting real-time applications as it is an event driven, asynchronous I/O which means it scales well.

Pusher

The final piece of the puzzle is Pusher. Pusher makes working with WebSockets extremely easy. It basically wraps the complexity of setting up and configuring a scalable WebSockets architecture up in a series of API calls. In this scenario the display application, which showed the real time updates of the edits, were pushed to the browser using the Pusher API. The other nice thing about Pusher is the the debug tools it comes with which allow you to see in real time the clients that have opened a connection up and the responses being sent from the server.

Applications similar to this do already exist, I think the significance of this architecture is the simplicity. By bringing together the right applications I only had to write 61 lines of code on the server-side and less than 400 lines of code on the client-side (total for both web pages) to achieve a relatively complex process. As services and application proliferate, utilising the correct combinations will become critical to ensure the time we spend coding web apps has not already been done for us.

So please play with the editing application and the real-time display application from the live demo – or view the video below – and let me know if you have any feedback.

About Data FME 2012 FME Server Google Maps HTML Oracle Spatial Data Web Mapping

Stewart Harper

Stewart is the Technical Director of Cloud Applications and Infrastructure at Safe. When he isn’t building location-based tools for the web, he’s probably skiing or mountain biking.

Related Posts