Realtime with Laravel Reverb
Playing
06. Customising broadcast event data

Episodes

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

Transcript

00:00
We've got a ton of data here being broadcast. Let's go ahead and see how we can control what is actually broadcast to all of our clients.
00:08
OK, so inside of here, we've currently got a user. Let's just work with that for now. Now, in any event class that you're broadcasting, you can define out another method called BroadcastWith.
00:22
This is going to return any data that you want to send through, typically an array. So let's go and just return an empty array for now and just see what this does to our event.
00:32
If we head back over and just reload our event here, you can see that, sure enough, we now get an empty array. The good thing about this is now we can customize and control the exact data that is sent down.
00:43
So if, for example, we were creating out an event that broadcasts that a new message had been put into a chat, we just need to figure out what data we really need.
00:52
So typically, this would just be everything that you want to display. You could use a user ID. So let's go ahead and reference the user
00:59
that we have as that public property and the ID. And then let's do the same thing for the name here as well. So let's swap that over to name. And now we have nice structured data
01:09
that's not going to get in the way. It's not going to send too much data down, and it's not going to reveal too much about that model. So if we head back over, reload this event, there we go.
01:19
We've got that user object in there, but it now only contains the data that we need. And the good thing about this is what you could now do is more appropriately set this to a protected property
01:30
within your class, because we don't need to access this from anywhere else, and we don't need to broadcast all that data. And you'll see that that works in exactly the same way.
01:39
We still get the same data. Let's roll with the example of creating a chat interface, and we'll go ahead and make out a model called message. So this will contain all of the message data
01:51
that's been sent along with the user. We'll see adding it to this event as well. Okay, let's go over to the messages migration. And in fact, we won't change anything about this.
02:01
Let's just leave this as it is for now. So we'll go ahead and migrate this. Let's go ahead and manually fill in the data in the database just because we didn't create out of factory.
02:12
So let's just create a new record out in there. Okay, so let's go and grab in our web routes that message and pass that down as a dependency to this class as well. So we'll just find the first message,
02:25
and then we just repeat the process. So when a new message is posted, we also want to take in the message that has been sent so we can display it within a chat interface.
02:37
In this case now, we just want to go ahead and build out an entirely new structure for this message that has been posted. So we just do exactly the same thing.
02:47
So in our case, we just have an ID here, but you would include the body in here as well. Okay, now that we've done that, let's go over and give that a refresh, and there we go.
02:56
We've got all of the data that we now need to react on the client, update something, and display something on the page when a new message rolls in.
03:05
So the key takeaway here is just be mindful about the data that you're sending through publicly to this because it will be automatically available to any of the clients that you broadcast to.

Episode summary

In this episode, we're diving into how to customize the data you broadcast to all your clients—in other words, how to control exactly what information gets sent out during broadcast events. We start by looking at the default data that's being broadcast and quickly see that sometimes it's way too much. Then, we introduce the broadcastWith method in your event classes, which lets you return only the data you actually want to send (think of it as a filter for your broadcast payload).

We play around with broadcasting just a user ID and name, rather than the whole user object. This keeps your client-side code simple and protects any sensitive data you don't want exposed. Plus, it makes the event leaner and quicker to send!

After that, we look at a practical example by building out a basic chat message system. We create a message model, hook it into the broadcast, and ensure we're only pushing the relevant info to the clients—like the message content and the user who sent it, nothing extra. By the end, you’ll see how easy it is to structure your broadcasted data so the frontend gets exactly what it needs, and nothing more.

The big takeaway: Always be intentional with the data you broadcast. Anything you send is visible to connected clients, so keep it tidy and secure!

Episode discussion

No comments, yet. Be the first!