Your web application is all shiny and new – it uses the perfect combination of the new cutting edge API everyone’s talking about, and a few old standbys. The only problem? You keep refreshing the page to see if something happened. You know, if someone signed up, or posted, or commented – or whatever it is your application does.
Those real-time APIs are for much more than just the sample chat applications.
They exist because it’s fundamentally hard to ensure real-time communication across a variety of platforms. It’s not even easy to have bi-directional communication across the two platforms that started the web – the server and the browser.
Sure, sending a message to the server is easy, it’s called a HTTP request and it happens every time you load a page. Sending a message to the browser is easy too, assuming it’s in the form of a HTTP response. But what happens when you want to send a message to the browser without waiting for that HTTP request – without that page refresh.
Each API has a unique profile: PubNub only charges for messages, not connections, and seems to have a client library for anything platform you can think of. Beaconpush has the notion of users as well as channels, and an on-site hosted version. Pusher has a nice security token implementation, and recently started adding webhook support for delivery of certain events. And finally, x-stream.ly is a developing API with real promise, a fairly customization security token model, webhooks for messages, and even acts as a broadcast proxy for Twitter’s streaming API.
Instead of having to implement some kind of long polling or web sockets yourself – then manage and scale that implementation – these APIs make it simple to add real-time communication to many different platforms. And for those just hacking around on different ideas – they provide the glue to quickly stick other APIs and services together.
The use cases for these APIs are pretty plentiful. Here are a few real live examples – all things I’ve worked on – starting with an integration of the standard chat concept into another larger scale system.
One application I’m working on – BeckonCall, a medical messaging application – will use a real-time API to enable communication between the user’s mobile application and the person sending the message from the web. It should be noted for this use case, none of the APIs replace something like UrbanAirship for pushing notifications to the mobile device when the app isn’t running – but complement that kind of push allowing real-time updates when the app is running.
Combine one of these APIs with a telephony API, and you have a real-time dashboard showing incoming calls – I built a version of that using PubNub and Twilio to display live radio call in contests with NthCaller.
Use a real-time API to publish any kind of event, and you can track site visitors, conversions, downloads, or even votes as they happen – it only took a few hours to combine PubNub and Nexmo (where I’m currently working as a part-time developer evangelist) to create a voting application for StartupWeekend AnnArbor.
Or take an audio or video streaming API – like TokBox’s OpenTok – and a few spare laptops as inputs, then use the real-time API of your choice to switch between them. Now you have a simple, multi-camera web broadcast – something I’m throwing together as a demo to promote Lehigh Valley Hack, an upcoming local hackathon, at our next local tech meetup.
So stop refreshing that browser, or polling from your mobile app, get a little pushy, and take a look at what these real-time APIs can do for you.
Photo via Blake Patterson