Introducing Rebound, a realtime channel authenticated web socket implementation. Inspired by Pusher and Laravel Echo, built on top of

With Laravel 5.3 just around the corner we can look forward to some great new broadcasting features. Taylor has been working away providing us all with some great new features, bridging the gap between NodeJs’s ability to work in realtime and PHP’s request/response base.

We can already benefit from realtime features in 5.2, but as anyone could have predicted the first “request” was and still is event authentication.

There are open source realtime packages out there, but authentication seems to be either really hacky (parsing external app session cookies, etc).

Enter Pusher. Pusher is a paid SASS that brings you channels, and authentication via its language apis.

Pusher looks to me like Taylors “realtime of choice” and as such the broadcasting features of Laravel reflect that with “channels” and “events”. It’s a very Pusher-like system.

As per the docs this can be implemented in something like, but its kind of shoe-horned in by pre-pending the channel name to the event name: channel::App\\Events\\Event. You could argue this can be abstracted by use of “namespace’s” or “rooms” part of the api.

I found a few problems with this:

  1. Your server needs to know and create all of the “namespace’s” before its started. In an ideal world the socket server just simply act as a proxy between the app and ui. Having to go back and create the namespace’s whenever your update your app isn’t the end of the world, it’s just not very DRY.
  2. Your UI is not using the same abstractions. Your app sends “events” on “channels”, but your JavaScript needs to join “namespace’s” and listen to “events”, or globally listen for channel::event events.
  3. Authentication seems to be a little hacky, you need to store your sessions in something the node process can access, you need to parse the encrypted Laravel cookies to get a session id, then fetch the session from the store, then have business logic within the node process to determine if they are authenticated.
  4. Authentication also seems to be an “all or nothing” deal. I’m sure this isn’t the case and some wizards could get it working, but for me it seems more hassle than its worth.

Laravel Echo

Recently Taylor announced the release of Echo, a simple abstraction of the pusher API to use within your Laravel project. Its use it targeted at Laravel 5.3 where you can per channel authenticate users.

This got me thinking … Echo is (as anything Taylor releases) really nice. But I could already see the backlash coming “Will it work with”.

The answer obviously would be a no. But why should we be tied into a paid service? is built on a very powerful and stable realtime communication layer called is what handles all of the transport upgrading, sending-receiving events. So I decided to build Rebound on top of, an Echo inspired JavaScript package which will allow all Laravel developers to maintain the same API when using either Pusher/Echo or Redis/Rebound.


Rebound is heavily inspired by all of the above mentioned solutions,, Pusher, Echo and It is a set of packages (client and server) that use as its communication layer, the Pusher “way” of subscribing to channels and events, and the Echo API interface to deliver realtime events to your application.

Rebound is targeted at Laravel, however with the way its built it could work with any system (going forward).

All it needs is a Redis connection where it can subscribe to events.

There is no need for Rebound to hack session data, or authenticate on connection. It receives channel subscription requests from the client, and relays the request to a post url (in Laravel). The result of that request determines if you can or cannot subscribe to events on this channel, simple (it does some other cool stuff like caching the responses within Redis as well to reduce load on your app).

When Laravel 5.3 is released hopefully  the rebound driver will be included in the core. Using it will simply mean installing the dependencies and running node websocket.js.

In a follow-up post I will go through the API and how to use it, until then checkout the in the client and server repo’s for usage examples.