Realtime with Laravel Reverb
Playing
05. Adding data to events

Episodes

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

Transcript

00:00
We're successfully listening for this example event within our application, but at the moment there's no data inside of it. That's not very useful because if you're building something that broadcasts an event, you're going to expect to use some of this data to show something on the page or modify some sort of state.
00:16
So if we head over to our application, let's go back over to that example event and let's just add a public property to this just to see what happens. So I'm going to go and create a public string out here called message, and I'm just going to say, hey, let's go ahead and broadcast this event now and see what happens.
00:37
So if we head back over to the browser, just give everything a refresh and rebroadcast that event. As you can see, this is now broadcasting a message to all of the people who are currently connected to this channel. It's easy to forget when we're building real time
00:52
that we could have thousands of people currently on their dashboard and as soon as we just dispatch this event within here, this will be delivered to every single person. OK, so defining these out individually like this obviously isn't what we want to do.
01:10
What we really ideally want to do is pass through data into our constructor, which is going to show data about a model or something like that. So let's get rid of this example property here and let's look at something more useful. OK, so back over to our web routes.
01:26
Let's go and find a user and pass them in as a dependency. If we were building a chat application, we will, of course, want to know who posted a message and we want to see the contents of the message as well.
01:40
Obviously, because this is just a constructor, we can pass any data we want in. So let's go ahead and fetch my user out of the database and pass that directly into this example class. Let's just double check that we have a user with an ID of one and yeah, that looks good.
01:56
OK, so over an example, now we can accept this into here and now technically what we're doing is putting an entire model in, setting it as a public property. Let's see what happens now when we broadcast this event.
02:11
So let's go over and resend that cross and as you can see, Laravel has serialized this down to JSON and you can see all of the data about this user. So pretty straightforward now, you can just pass any data
02:26
into any of the events that you create, make sure that they are public properties and these will be available in the payload. Let's just look at an example of what happened if we did set this to a protected property,
02:38
which of course we could do and we'll see the difference. So if I go ahead and broadcast this, you can see that that data is not shown. So a really important part of events and when you're broadcasting is we need these to be public, but that could also be a bad thing.
02:55
If you are passing a bunch of models into here, particularly when you look at your users, notice the amount of data that we get inside of here. This gives away a lot about the current user that we're broadcasting.
03:09
So we want to be really, really careful here about the kind of data that we're broadcasting to all clients for a couple of reasons. First is security. If you had properties in here that you don't want broadcast to all clients,
03:22
then you're going to want to restrict this. And of course, speed as well. You don't want to send more data than you need to your WebSocket server. So let's jump over and look at how we can control this data.

Episode summary

In this episode, we start by pointing out that while we're listening for events in our application, these events aren't very useful unless they come with some data. So, we walk through adding a simple public property—like a message—to the event and see how it gets broadcast to everyone connected to the channel. This is a nice way to demo that data is really being sent out in real time.

Next, we explore a more realistic scenario: instead of just using a hardcoded string, we fetch a user from the database and pass that whole user object to the event. This lets us see in the browser how Laravel automatically serializes the user data into JSON and includes it in the event payload.

Along the way, we point out some important considerations. For example, only public properties of the event will be included in the broadcast. If you set a property to protected, it won't show up in the broadcasted data—something to be aware of!

Finally, we caution about security and performance: broadcasting entire models (like users) can expose sensitive data and send much more information than necessary. So before moving on, we mention the need to be careful about what you include in your broadcasted events, hinting that we'll look next at how to control exactly what data is sent.

Episode discussion

No comments, yet. Be the first!