Using Pusher to Enable the Real Time Web
At the R/GA London Make Day, the London office split into small teams to try and create, well, anything. Whilst some people were more existential, my team aimed to gamify the “Tea Round”, an important part of the London office routine.
A key concept of the game was that all users would be kept in sync ‘real-time’. As with any hack day event, development time was limited and so there had to be compromises. Whilst our original plan was to use websockets and node.js to keep the game engine and players in sync, as the time ticked by we realised that we wouldn’t be able to build out a full node.js integration to the level we would need to demo our prototype.
What we needed was a shortcut, a framework or a service that was going to help us, and help us quickly. Over the last few years there’s been a growth in the number of companies who offer real-time functionality as a service, such as BeaconPush, PubNub, Spire.io and Pusher.
For Make Day, the team plumped for Pusher, not due to a complex set of evaluation criteria (we were up against the clock), but because the Pusher team are based at the Silicon Roundabout, just round the corner from the London office. The Pusher service allowed us to quickly enable real-time communication (and leverage their debug tools to track where things were going wrong with our hastily written code).
Although it does introduce another moving part, there are a number of benefits to this. You don’t have the pain of setting up and maintaining the infrastructure for real-time socket based communication, and theoretically the provider takes care of the scalability problems through their cloud provisioning.
Using the Pusher service meant that in less than an hour and with just a few lines of code, the Make Day team had real-time game data, synchronised between phones, servers and desktop devices. This allowed us to keep each player at exactly the same stage of the game and give the competitors real time status updates on the progress of their rivals.
So the good news is that this can help keep costs and development time down allowing developers to concentrate on coding features and not worrying about managing complex messaging. The bad news is that you might end up having to make tea for the rest of your team!