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.
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 socket.io, but its kind of shoe-horned in by pre-pending the channel name to the event name:
. You could argue this can be abstracted by use of “namespace’s” or “rooms” part of the socket.io api.
I found a few problems with this:
- Your socket.io 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.
- 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.
- Authentication also seems to be an “all or nothing” deal. I’m sure this isn’t the case and some socket.io wizards could get it working, but for me it seems more hassle than its worth.
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 socket.io?”.
Rebound is heavily inspired by all of the above mentioned solutions, Socket.io, Pusher, Echo and Engine.io. It is a set of packages ( client and server ) that use Engine.io 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