By Craig Buckler

How to Use WebSockets Today With Pusher

By Craig Buckler

Brian Raymor’s recent SitePoint article, WebSockets: Stable and Ready for Developers provides a fabulous overview of the technology. In essence, WebSockets permit asynchronous bi-directional communication between the client and server. A connection is held open so lightweight messages can be sent from either device at any time. It’s an ideal solution for real-time chat and games and is likely to be more efficient than Ajax polling.

That said, there are a couple of drawbacks:

  • WebSocket technology is relatively new and, at the time of writing, it’s only fully supported by Firefox and Chrome.
  • Even if your browser supports WebSockets, there’s no guarantee it’ll be natively supported by your server platform.

Stable and ready? Perhaps not yet.


Fortunately, there’s another option if you’re desperate to exploit WebSocket technology today. Pusher is a new service which ployfills over the gaps in WebSocket implementation:

  • Pusher is a proxy service that sits between your clients and server.
  • On the client, Pusher provides a range of WebSocket libraries for JavaScript, iOS, Android, Flash, .NET, Silverlight, Ruby and Arduino.
  • If you’re using a browser which doesn’t offer native support, the JavaScript library automatically imports a Flash-based shim which implements WebSocket technology on IE6 to 9, Chrome 1 to 4, Firefox 1 to 3, Safari 1 to 4, Opera and Android.
  • On the server, Pusher provides a range of WebSocket libraries for PHP (generic and framework options), Ruby, ASP.NET (C# and VB.NET), Python, Node.js, Java, Groovy/Grails, Clojure, Coldfusion and Perl.
  • If you’d prefer not use the WebSocket API for triggering server events, you can adopt Pusher’s REST API.

The whole process is reassuringly simple. Once you’ve registered for a Pusher account, you’ll receive an API key. Your HTML5 page includes the JavaScript library, establishes a connection and subscribes to a named channel:

<script src="http://js.pusher.com/1.11/pusher.min.js"></script>
var pusher = new Pusher("YOUR-PUSHER-API-KEY");
var channel = pusher.subscribe("my-channel");

You can then define callbacks that bind to events coming in via the Pusher socket:

channel.bind("my-event", function(data) {
	alert("An event was triggered with message: " + data.message);

To send a message from PHP:

$pusher = new Pusher($key, $secret, $app_id);
$pusher->trigger( 'my-channel', 'my-event', array('message' => 'hello world') );

The Pusher website provides full documentation, a selection of tutorials for PHP and Ruby and a showcase with case studies which might inspire your next world-beating real-time app.

I like the concept behind Pusher. It’s a great solution if you want to try WebSockets today while supporting the majority of browsers and native OS platforms. There are free plans for experimental prototypes as well as paid accounts for heavier usage.

For more information, refer to Pusher.com.

  • I dislike it just because it doesn’t use the real websockets API, and it puts an extra server between the client and the host… That latter part is the real deal breaker for me as why on earth would I want the increase in latency and all my data passing through another company? That proxy part is making my scammy sense tingle.

    Scripting is slow enough as it is without adding the overhead of an extra proxy and wrapping all the functions in another API. Not sure I’m even seeing an advantage to this over a REAL polyfill like web-socket-js; which provides the flash fallback WITHOUT all this extra nonsense.

    • Patrick

      I think the point of Pusher is that it takes care of setting up web-socket-js (and a few other frills) for you, hides a lot of the configuration steps necessary to getting websockets working, and provides APIs for use in server-side languages. Having said that, skilled developers (the kinds of people you’d expect to be developing apps that actually need to use websockets) shouldn’t have much trouble setting those things up on their own. And I agree with you that even on a conceptual level, the service has some fairly fundamental flaws which would prevent me from using it.

  • Patrick

    I was waiting for this. “Stable and ready for developers” was an utterly misleading title. Unfortunately the original article didn’t really provide a “fabulous overview” of websockets – more of a “basic summary” in my opinion. And because the article was predicated on an exaggerated claim about the readiness of the technology, it failed to explore services like Pusher which are absolutely relevant, and at this stage required, in any discussion of the applications of websockets. Once again, Craig Buckler has to step up as SitePoint’s voice of reason and publish a follow-up article to fill in the gaps left by previous authors.

    Of course, the sad reality is that websockets probably won’t become widely used for another few years. Browser support currently exists only in the latest few versions of FF and Chrome, and when your “fallback” mechanism is what’s actually being delivered to 90% of your users, using services like Pusher is more like using websockets as a “fall-up” mechanism for those people who actually use a modern browser.

    Pusher is an interesting idea, and obviously one that’s been developed by people who know what they’re doing. I’m wary of letting a 3rd party handle my data for me though – there are some concerns of security, performance and reliability. And using a Flash-based fallback? I love Flash, but downloading a SWF and instantiating the Flash Player is a lot of overhead to incur for what should be a basic task (communicate with the server). Since the point of using websockets is ultimately to reduce system load and improve performance, this seems kinda counterproductive, especially as it’s what a large majority of your users will actually be using instead of real websockets communications. Server load may be lower overall, but at the expense of increased bandwidth use, longer initial page load time and higher client resource consumption. And of course, there are always issues with people blocking Flash, so there’s still a population of users out there who you can’t reach.

    Websockets are a great idea, and I can’t wait for them to become useable without having to polyfill the functionality into older browsers. But until then, I’m not convinced the extra effort is worth it from a development, performance, security (and possibly financial) standpoint, unless your application really, really needs websockets features. I don’t think the merits of a service like Pusher really outweigh the pitfalls. I think we’ll have to wait for browser support to improve before we see any widespread use of websockets technology. And given the sluggish pace of web standards development and proliferation, I’m not holding my breath.

  • Hi guys,

    I’m one of the co-founders of Pusher. It’s interesting to hear your thoughts. There are some points you’ve raised which I can hopefully shed some light on.

    At Pusher we’ve made sure that any client connecting to the server can do so whether they have native websocket support or not. However these days we find fallback being the exception and websocket support more common. As time goes on this will only improve. We also provide support beyond just the browser, including libraries for host of different environments where there isn’t native support (e.g. iOS),

    As for our API, Pusher provides several layers of functionality on top of the basic websocket protocol. This includes the pub sub messaging system, presence and authentication. To do all of this, we’ve obviously had to build in our own simple protocol and client side API.

    Where latency is concerned, the routing times inside our system as so fast, that coupled with the low latency of most server-to-server comms, the extra server hop is never an issue.

    I hope you find the above useful and find some time to try out the service.


Get the latest in Entrepreneur, once a week, for free.