This guest post comes from Phil Leggetter, Developer Evangelist for Pusher. Phil has developed and worked with real-time web technologies for over 10 years and has written for Programmable Web in the past.
Pusher has established itself as a leading service for delivering WebSocket messages to connected clients via its simple, RESTful Pusher API. This especially suits application developers working with languages and platforms that struggle to maintain and scale persistent connections. We remove the need to roll a custom solution and work with complex and unfamiliar technologies, and ensure the benefits of a hosted service can be achieved. We’ve recently added support for WebHooks, which provide a different sort of real-time solution.
For some developers, getting feedback about the users and devices that are connected is critical. An application may want to only send broadcast messages when there are people connected, or perform some task when they do so. We therefore needed to come up with a solution to send real-time notifications to these applications. We decided that WebHooks are the answer and in this post I’ll explain what WebHooks are, why we decided they were the best solution and how they can be used.
WebHooks are an HTTP POST callback request sent to URL of a user’s choice in response to some event occurring. They offer simple and effective server to server communication without long running connections. As discussed on the WebHooks wiki they have a number of uses; we’re using them to send real-time events.
One of our primary goals of Pusher is simplicity. We provide clear and simple APIs for developers and hide away the complex distributed system handling all the messages and events which occur inside Pusher. The server to client message distribution aspect of our service has been a success but we’d also like to make it simple for developers to consume some of our internal events so that they can build more powerful apps. WebHooks fit the bill perfectly because they offer a fantastically simple and elegant way for servers to send each other notifications.
WebHooks mean an app can receive relevant real-time events that are happening with connected clients in a way that is easily:
In our first release WebHooks give developers access to two core events:
* When a channel is occupied: at least one user is subscribe to a channel
* When a channel becomes vacant: there are no longer any users subscribed to a channel
Here are a few examples of how these events can be used.
Prior to our WebHooks functionality being available it was possible for event messages to be published by an application server to a channel without knowing if anybody was listening. This would mean that the app is using server resources to make an HTTP request to our REST API to publish messages that don’t actually get delivered to anybody. Now it’s possible to decide whether or not to publish an event message on a channel based on whether it’s occupied or not.
It can also be used when integrating with third party data sources such as Twitter. In our Filtrand demo (blog post), which uses WebHooks, we use the name of the channel (e.g. ‘programmableweb’) that has become ‘occupied’ to identify keywords to search for via the Twitter Streaming API . Only when a channel becomes occupied do we begin our search for that Twitter search term and publish messages to that Pusher channel. When the channel becomes vacant we unsubscribe from that search term and stop publishing data to that channel.
I’m particularly excited about this use case, especially when integrated with rich data services such as DataSift.
Our presence functionality has been very popular, but there might be some scenarios where a different solution is required. For example, a single channel being occupied might mean that a user is online. By using WebHooks in conjunction with standard application server functionality the application can easily tell if a user is online with the added benefit of being able to send real-time messages directly to them.
WebSockets offer a fantastic way of achieving bi-directional communication between clients and servers, but for server to server communication HTTP is likely to be here for a long time to come. This is simply because there has been a definite focus on the progression of client technologies and we are going to have to wait for the majority of server infrastructures and solutions to catch up.
Because WebHooks offer an easy and powerful way for applications and services to integrate with one another, we believe that the trend towards an interconnected and interchangeable set of loosely coupled cloud services, talking to each other via HTTP requests, is set to continue.