Realtime with Laravel Reverb
Playing
10. Broadcasting to private channels

Episodes

0%
Your progress
  • Total: 1h 19m
  • Played: 0m
  • Remaining: 1h 19m
Join or sign in to track your progress

Transcript

00:00
Now that we've defined, authorized, and connected to our private channel, it's time to send an event through.
00:07
Okay, so we know how to do this already. Let's go ahead and create out an event. And we are going to make this a order dispatched event. So let's go ahead and create out an event called order dispatched.
00:21
And we already know how to broadcast this. Let's go over to our web routes. And let's define out a route to do this like we did in the last section. Let's just call this broadcast.
00:30
And of course, this can be sent from anywhere in your application. So for example, within an admin panel, when something is marked as dispatched, you just want to broadcast this. Okay, let's go ahead and broadcast this new order dispatched event.
00:46
And what do we need to be able to actually dispatch this? If we think about it, inside of our channels, we need to know which channel we are broadcasting to. And that needs to have the user's ID within that channel.
01:01
So with that in mind, we need to pass through the user into here so we can extract the ID out and broadcast the correct channel. So let's go ahead and grab out just my user. And of course, this would depend on the order that had been dispatched.
01:15
And let's accept this into our constructor. So for now, we'll just go ahead and set this as a public property without modifying the contents of the broadcast. But we already know how to do that.
01:27
Okay, so now that we've done this, let's come down to our channel section. And by default, this is set to a private channel. Great, we don't need to change anything there. But we do need to broadcast to the channel name that we've given,
01:38
which includes adding in the user's ID. So instead of this being a hard-coded value like chat, we want this to be a dynamic value depending on the model that's passed in. So let's go ahead and say this user ID.
01:52
Now we know that we're broadcasting specifically to the channel that that user is potentially listening on. And that will include their ID. Okay, let's go ahead and try this out.
02:01
So we're going to go over and go to that broadcast route that we just defined. We won't see anything yet because we're not listening at the moment. But if we head over to our server, we should see we've subscribed to this
02:16
and we'll eventually get our event in here when we're listening to it. So you can see now we've got an auth token. So that was the difference before. And we know that we are broadcasting to users.one.
02:27
You can ignore the private prefix because all of that is handled when we use the channel name within this just here. So this will automatically prefix this with private for us. Okay, let's go ahead and listen for this event then.
02:43
So the syntax here is exactly the same. We listen on a private channel to the order dispatched event. And then we go ahead and introduce our closure. We still get any of the event data through that we've passed through.
02:58
And for now, let's just go ahead and console log out that event. Great. Okay, if we head over, give everything a refresh and try that, we should see this rolling. Now we don't at the moment.
03:09
That is just because we have forgotten to include the implemented interface to actually broadcast this. So let's say implements should broadcast now. Again, you can queue this.
03:21
This is the type of notification that you could queue because it's not an immediate thing that needs to be sent right now like a chat. Okay, let's try this out one more time. And there we go.
03:32
So we've got all of the details about the user. And of course, we already know how to pass additional models in and structure the data how we need. For now, we'll just go ahead and leave this as it is.
03:42
Okay, so let's go over to our dashboard. And let's do something useful for this. So let's provide out some data. Again, this is all Alpine code.
03:51
If you're not familiar with this, we're just storing some data in here. And let's store whether something has been dispatched. So imagine that you're on an order page. This could relate specifically to the order ID.
04:05
And you could authorize the user who owns an order. We'll be looking at that in just a bit. But for now, let's just keep this really simple. Okay, so inside of the area just here,
04:16
let's create out a template. And this will only show, so we'll just say the if, if we have dispatched that order. So if this value is set to true.
04:26
So in here, let's just create out a div or a paragraph and say, order has been dispatched. And we should be good. In here, once we get that order through, we can go ahead and set this.
04:39
So let's set dispatched to true. And everything should update. Okay, if we come over, we don't see anything on the page, but as soon as we hit this, when the event rolls in,
04:49
it will set that to dispatched. Now, this isn't working at the moment just because I've used V. We need X if dispatched. And let's just try that one more time.
04:58
And there we go. That immediately shows that our order has been dispatched. Let's go ahead and make this a little bit more useful by actually creating out an order model.
05:08
So let's make out a model in here. And we'll call this order, of course. Let's create a migration and a factory for this. And let's fill in some of the data that we need.
05:18
So let's go over to the create orders table migration. We know that an order needs to belong to a user. And this is important because we're going to be changing this up soon to authorize should we actually send this to the person who owns the order.
05:33
So let's add a foreign ID in here for the user ID. And we'll constrain that. And we'll just leave it at that. But obviously, this would contain any of the order details that you have.
05:43
So let's run our migrations. And let's immediately go into Tynker just to generate out a fake order. So let's go into app, models, and order. Let's go and grab out the factory that we created.
05:57
And let's create this out using our user ID. So now we own that order. OK, once we've created that, we now have an order that belongs to us. And if we head over to the web routes, we can now pass this in
06:10
so we can get some of them order details. So let's pass in order one. And let's accept this into order dispatched. So let's create out our order in here to receive in.
06:22
And there we go. What we can now do is show any of the information about this order in here because we are sending this down with the event. So we might store the order somewhere in here.
06:31
By default, it would be null. And event, remember, is now going to contain that order object. So we can set the order to the event order that we get in. And then down here, we can output some information about that order.
06:45
So for example, in here, we might have a span with the order number. So let's go and use x text to output order ID. And that should now contain all of the information that we need. Let's go ahead and try and run this.
07:00
And there we go. Order one has been dispatched. So this is a global event on a dashboard. You could use this for stuff like notifications globally in your application.
07:10
In a bit, we're going to look at having a specific orders page where we listen on a channel for that order only. But for now, at least we now know how to broadcast through to private channels, send the data down, pick it up, and display it.

Episode summary

In this episode, we dive into broadcasting events to private channels in our Laravel project. Now that we’ve got our private channel set up and authorized, it’s time to actually send an event through it. We work through creating a new event (like OrderDispatched), figure out how to dynamically broadcast this event to a channel that includes the user’s ID, and set up all the PHP-side essentials to make broadcasting work seamlessly.

On the front-end, we wire up everything so that when our event is broadcast, the client hears about it and updates the UI right away. As part of the walk-through, we model a simple dashboard scenario: when an order is dispatched, the interface instantly reflects that state change. We see how to use Alpine.js to respond to the broadcast and display order information dynamically.

You’ll also see how to set up an orders table, generate fake data with factories, and make sure orders are related to users. This is handy for authorizing broadcasts only to users who should see them, which we hint at and will build upon in the next episodes.

By the end, you’ll have all the pieces connected: the backend broadcasts an event relevant to a user, the frontend listens on a private channel and updates accordingly, and you’re ready to power real-time features like notifications or order status updates throughout your app.

Episode discussion

No comments, yet. Be the first!