Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Taylor just posted a new video about a new ShouldBroadcast event type that will be included in Laravel 5.1. Right now the broadcast driver implementations include Pusher, redis (+socket.io), and log. I'm wondering what the benefit of Pusher is over PubNub. Or, in this case, why Taylor would favor Pusher over PubNub. I'm about to start a project where real-time updating is required and after a bit of research decided to go with PubNub as they seemed to be the more authoritative and robust offering. However, I'd love to get opinions from the community on why you feel one should be used over the other. Thanks!
Pusher is incredibly popular, so I'd imagine his decision to offer that over PubNub probably doesn't extend beyond "never felt the need to try something else." If PubNub is as popular, he might consider a driver for that. You'd have to file an issue on GitHub to see.
Personally I'd go the socket.io route. Why rely on a third party (possible costs) plus the inevitable latency?
@sitesense not everyone can install node on his (shared) server :)
@pyxl of course, and if you can stay within the limits of the free tier of a service like Pusher, that's fine. If not, you might be better investing the money that you would use for this service to get something other than a shared server :)
@luoshiben - The Pusher vs PubNub question has been covered quite extensively in Why does the Laravel community seem to prefer pusher over PubNub for real time notifications?. I don't think there's much more to be added to that, but I'm happy to field further questions.
they seemed to be the more authoritative and robust offering
I'd be very interested in getting your feedback on why this is your opinion. Please feel free to ping me via phil @ pusher.com.
A couple of quotes from @sitesense I'd like to comment on:
Personally I'd go the socket.io route. Why rely on a third party (possible costs) plus the inevitable latency?
The internal latency on our multi-tenant clusters sits at around 10ms. So, from the point of an event (message) hitting our servers to it leaving our systems takes 10ms. The rest of the latency is entirely down to the speed of light and external network factors. When you use a third party service there may be an additional hop that messages have to make so that does need to be taken into consideration e.g. Client -> Server -> Other Client vs Client -> Server -> Service -> Other Client. However, you can also send messages to other clients via hosted services e.g. Client -> Service -> Client.
There are also other benefits to hosted service that mean latency is managed... see my next point below.
If not, you might be better investing the money that you would use for this service to get something other than a shared server :)
One of the benefits of a hosted service such as Pusher, PubNub, Realtime.co, Hydna, Firebase, Data McFly, Fanout.io etc. is that they manage the infrastructure and focus on keeping that latency down. If managing your real-time infrastructure and managing latency is something you want to do, or there are other factors that mean you feel you need to host your own real-time infrastructure then going self-hosted is of course an option.
Pusher also offer dedicated clusters for larger customers so that is also an option if you'd prefer not to share infrastructure with others.
I'm obviously delighted that Taylor has decided to write a PusherBroadcaster. But, the interface, and thus implementation, is so simple that it will be easy to plug in another service provider. The Redis integration also makes if very simple to integrate any other real-time framework.
A general point on Socket.IO and choosing a real-time framework/service - Socket.IO has been amazing for the real-time technology space - a space that's been around since 2000! Although there are now many implementations of socket.io in multiple languages, the official Node solution came around at just the right time to ride both the Node and WebSocket wave. But it's not your only option and anybody deciding that they need real-time functionality should take their time to make sure they pick the right solution for their use case. For reference, I gave a 10 minute guide to choosing a real-time framework talk at ForwardJS 2 this year and back in 2013 a 30 minute talk on the same subject at FOWA.
@sitesense Agreed, in many cases rolling your own with socket.io would definitely be the best approach. In my case, I need to service users around the world in a mission-critical fashion and would rather not build out the global infrastructure required to do that. To leggetter's point, that's the beauty of Pusher and PubNub; They focus on this job and both seem to do it very, very well. Also, fortunately in my case, a small amount of latency isn't an issue.
@leggetter I know that both Pusher and PubNub are widely used and both are excellent services. As my original question was in regards to pros/cons of the two, and since you asked why I felt that PubNub may be a better offering, here are impressions I get (for what they're worth!) on the two products when visiting the websites:
Pusher
PubNub
After a review of the two sites and a comparison of the offerings based on the information presented, I felt that PubNub was the more robust, reliable, scalable, and feature-rich offering. Specifically, two of the main features that attract me to PubNub that Pusher doesn't seem to offer are storage and playback capabilities and the ability to send through mobile push gateways. However, maybe there is more parity between the these services than observed, and it could just be that PubNub has done a better job of marketing and providing information.
My goal here isn't to evangelize PubNub over Pusher. On the contrary, I simply want to find the best solution for my use case. I highly respect Taylor and Jeff, and their pseudo-endorsement of Pusher makes me want to take a second look. In the end, I think that Pusher, PubNub, socket.io, and many other competing and related solutions are all extremely valuable tools, and what is right in one case isn't necessarily right for all cases. The Laravel community is great at sharing ideas, and I appreciate everyone's input. "Which is best" aside, I'm just excited to see event-based broadcasting in any form become a 1st class player in the Laravel framework!
@luoshiben - amazing useful feedback. Thank you!
The data on messages is a bit out of date. We now deliver around 5BN a day. And a stat that I love is we've delivered 1.3TN since we started counting :)
We definitely don't do enough to highlight our features. But we're going to do something about this, which is why your feedback is very useful. Our features are:
$pusher->trigger('channel_name', 'event_name', $data);
We do have a feature called Event Buffer in the works that will ensure events (messages) that are triggered whilst clients are experiencing poor network activity are delivered. You can think of this as a form of message playback.
Hopefully that clarifies things further for you and anybody else that's interested.
@luoshiben @leggetter hi guy's, what do you think about... let's say, if a begin my project with 2000 users, or even 10,000 on a website like here, laracasts. Managing all the notifications, messaging, etc, how much work will get my DigitalOcean VPN? do you know or have some layout for this kind of configuration?
thanks !
Please or to participate in this conversation.