This is a guest post by Kevin Rohling, founder/ceo of cisimple.

Here at cisimple we’re really excited to be announcing the first release of our API. We’ve exposed functionality giving our users a new level of control over build processes for their mobile applications. It’s now possible to kick off new builds, download artifacts and more, all via API calls.

One thing we’re doing a bit different from most API’s is that we’re allowing clients to register for real time updates via Pusher channels. We’ve had several folks ping us, interested in developing apps that respond to build activity (i.e. build started, build passed, build failed, etc). In fact, one of our users, Romain Pouclet, developed an app that displays Notification Center updates on OS X using our API and Pusher. Exposing functionality via Pusher private channels lets us support these use cases easily.

The API

One of our design goals was to make it possible for someone to subscribe to a Pusher channel with nothing more than one of our API tokens. To accomplish this, we’ve added an API operation that returns a Pusher Key and Channel Name for an authenticated user. Internally, we scope channels at a user level, giving us the flexibility to add new events in the future. Making this part of the API also avoids hard coding any of these things into a client application.

Once the client has a key, authenticating the channel just requires sending along an API token. This also allows us a chance to do some bounds checking on our end. By using Pusher’s subscription counting feature (currently in beta) we’re able to limit the maximum number of open channels a user is allowed to have.

Pusher.channel_auth_endpoint = 'https://www.cisimple.com/user/channel/auth'; var pusher = new Pusher( pusher_key, { auth: { headers: { 'Authorization': "Bearer " + token } } } ); var channel = pusher.subscribe( channelName ); channel.bind('build-state-changed', function(data) { alert( "Build is " + data["build"]["state"] ); } );

On our backend, whenever there’s an update to a build we just post a message to the user’s channel using an event named build-state-changed . The message payload contains all the information the client needs to know about the build, like what Job it’s associated with, what state it’s in (i.e. QUEUED , STARTED , FINISHED ) and whether the build was successful or not.

We think using Pusher to make our API real time and bi-directional, opens up all sorts of new use cases. To learn more about the cisimple API check out the cisimple API docs.

The Resource Savings

Before exposing build notifications via our API we originally integrated Pusher into our Dashboard page. This page provides a live view of a user’s Jobs, or build processes, running in our system. At any time these jobs could be kicked off by a commit hook, API call, etc. and the Dashboard page needs to be constantly up to date to be useful, basically as close to real time as possible.

We originally decided we would poll the server on a regular basis, about a 5 second interval to keep the page up to date. As you can imagine, this quickly became our most expensive web operation. Also, since this required a number of database calls we were also tying up our DB. Not great.

Fortunately, this is a road we’ve been down before so we knew Pusher was a great solution to this problem. We deployed the Pusher integration late in the day on 2/23. Take a look at the graphs and you can almost here the fans on our servers spin down. Our web transactions went from taking roughly 8.5% of wall clock time down to about 2%. The database graph shows a similar decrease in load.





We love us some Pusher, thanks guys!

Now, get on over to cisimple to setup CI for your mobile app!

-Kevin Rohling (founder/ceo cisimple)

If you’re interest in mobile development then you may also be interested in joining the list for access to the beta version of the new Pusher Java Android library. Register for beta access now.