Realtime Messaging with Pusher

Tech Room

Every application has its dark corner. Some part of the application of which you are not proud of. That part of the application is working code, it’s in production for some time but you still have an uneasy feeling about it. You fear that it will come back at you at the worst possible time.

At Codeship one of these parts was our Dashboard reload. In this article I will show you how we made it awesome.

The Codeship Project Dashboard

When you are on your dashboard, or watching the builds of a particular project or observe a certain build. Watching the builds of a particular project

We are updating the page without you having to hit reload all the time. Every time a new build starts or we receive some new output from your test commands we update the page and you can see the changes instantly.

Back to the past

Previously, we did the most simple implementation you can think of. There was a Javascript timeout on each of the 3 pages and we would just reload the page every 10 seconds. That’s not close to instant but it got the job done and it worked for more than 1 year. That’s still impressive. As you can imagine there is a lot of room for improvements.

Realtime Updates with Pusher

Over the time we optimized this feature step by step. We added some checks which allowed us the respond with a 304 (Content not modified) for not having to render the page again and again even when there are no updates. The next step was to let the client save the last time it got updates from the server and included that information in the next request. This allowed us to just deliver the missing parts. We were still having that 10 second page reload. We decided to change that!

The web changed dramatically in recent years. Web sockets have been around for quite some time now and a huge ecosystem evolved around these new technologies. We never had the intention to implement our own realtime push infrastructure, thats totally out of focus. We needed somebody who handles and provides a reliable push infrastructure for us. In the back of my head i knew about PusherApp, checking their site in the past but never having a good use case to actually use Pusher.

37 changed files with 315 additions and 159 deletions.

Implementing Pusher was quite easy and really fun. Let’s go into the details.

Private Channels

PusherApp supports private channels, this basically means the Pusher Javascript asks your application if it is allowed to subscribe to the channel. They have a simple naming convention, private channels need to start with the word “private”. Our private channels look like this: “private-build-190852″ where 190852 is the build id. The same goes for the project channels.

The Javascript sends a POST request to /pusher/auth and you need to either return a 200 or a 403. You need to authorize the client with the pusher service to let them know the client is actually allowed to receive updates. Using the Pusher Gem this is just a few lines of ruby. How you decide if a client can subscribe to that private channel is totally up to you. In our case we check if the user is allowed to access the build or project.

def auth
    if pusher_access.can_access? params[:channel_name]
      response = Pusher[params[:channel_name]].authenticate(params[:socket_id])
      render json: response
    else
      render text: "Not authorized", status: 403
    end
end

Multiple Channels.

If you go to the Codeship Dashboard you can see multiple projects. If you have just 1 project you see builds from that project. If you have multiple projects you see the last 10 builds for these projects. In this case we subscribe to multiple channels. For example if I go to the dashboard I’m subscribed to the channels “private-project-7978″ and “private-project-211″. If there is a new build starting for one of those projects we send a message to that channel and everybody who watches that project in their dashboard gets the update.

The numbers

On a normal day we push 1.3 Million messages and have 300 concurrently connected clients.

Codeship – A hosted Continuous Deployment platform for web applications

What’s next

Right now we don’t include the updated parts into the message we send over Pusher. This means the client still does the page reload and gets the updates from the server. If we deliver the updates straight to the client we save a lot of requests which are not needed because we have the data that changed already in our hands at the time the push gets triggered.

What we think

We are very happy with the changes we made and Pusher itself. It made the application logic a lot simpler. We don’t check for not modified content anymore, since we only trigger reloads after changes happened. The next step is to push the modified content directly to all connected clients. I’m looking forward to the next improvements we gonna ship.

Let us know your experiences with Pusher. How do YOU achieve Realtime Messaging for your app?

Improve your dark corners today!

Further information

Subscribe via Email

Be sure to join 13,643 subscribers of our newsletter to receive updates on software development best practices, Continuous Delivery and tips and tricks to start shipping your product faster.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Pingback: Realtime Messaging with Pusher | Open World()

  • Philip Woo

    What an interesting coincidence. I was working on an app that required some realtime messaging and looked at how you guys were doing it for all the build updates. After some perusing, I found out that you guys had implemented that solution you described in your blog post to simulate ‘realtime’-ness. With some additional googling, we found Pusher and decided to roll with it like you guys.

    • https://www.codeship.io/ Manuel Weiss @codeship

      Great to hear Philip! Glad the article was useful to you :)

  • PB
    • https://www.codeship.io/ Manuel Weiss @codeship

      Thanks! Corrected it :)

  • Roman Kuba

    This is a test comment

  • Richard Seldon

    Manuel, thanks for sharing. Yes, lots of libraries and frameworks to do this – http://www.quora.com/What-are-alternatives-to-pusher-com. Firebase is getting quite a bit of attention recently in terms of hosted solutions. For self hosted, simple tasks, SocketIO is a lightweight approach, for REST like api with baked in support for web sockets, SailsJS is a great node Framework. Really interesting to hear about your implementation and pleased it has worked out so well – definitely going to take a look at PusherApp.

  • Richard Seldon

    Manuel, by the way, would welcome some information on how you have handled the security aspects when adopting Pusher. Firebase recently incorporated JWT (pronounced JOT) tokens to their API.

    • beanieboi

      Hey Richard,

      We do 2 things.

      1) we don’t push any sensitive data through pusher. we just ping the frontend to reload itself.

      2) We use private channels in Pusher. that means that the pusher javascript client asks our backend for a authentication token and uses the token to subscribe to the channel.

      best,

      ben