Now that we have Broadcasting enabled and Reverb installed in our application, it's time to work on our first feature, wiring up real-time messaging. Now just as a reminder, I can go in here and send a message, but nobody's going to receive that message until I refresh the page. And what we really want to do is use the power of real-time communication to make those messages appear to all users in real-time. Here we are in our ChannelVault component, and at the very bottom of the PHP section of the component here, we have our send method. You can see here that we are passing the message through to the send method on the channel model, along with the currently authenticated user.

You can see here that we are passing the message through to the send method on the Channel model, along with the currently authenticated User. Inside that send method on the Channel model, we check that the message has some content, and if it does, we go ahead and store it in the database against the authenticated User. And that's why when you refresh the page, you see the message appear on the screen. At the very bottom of this method, we are dispatching the MessageSent event. The MessageSent event is pretty straightforward. It accepts our Message model, and we are going to go ahead and load the User so that we know who the User was who sent the message. And these are set as public properties on the class, so that any listener hooking into

who the User was who sent the message. And these are set as public properties on the class, so that any listener hooking into this event has access to those properties. But those public properties are also really useful when it comes to broadcasting messages. We can go ahead and tell Laravel that we want the event to be broadcast to the front end whenever it's fired by simply implementing the shouldBroadcast interface. And you can see here that my editor is going to squawk at me because we are not implementing the broadcastOn method, which is associated with the shouldBroadcast interface. Let's go ahead and implement that now. The broadcastOn method is responsible for instructing Laravel on which channel an event

Let's go ahead and implement that now. The broadcastOn method is responsible for instructing Laravel on which channel an event should be broadcast from the back end to any listening clients. And you can see here from the return type that we are able to return either a single channel or an array of channels. So in our case, it's okay for the time being at least to return a single channel. So we can go ahead and write return new Channel, and we want to use Illuminate\Broadcasting\Channel. And then we can provide our channel's name. In our case, let's use channels.

And then we can provide our channel's name. In our case, let's use channels. And then we will use the ID of the current channel. With that, anytime this event is dispatched from our back end, Laravel will broadcast that on a channel called channels. And our given channel ID. Any client listening on that channel will be able to receive that event, and they will receive all of the public properties of this class within the payload. Let's take a look at what we need to do to wire this up on our front end. We are in our ChannelVault component.

Let's take a look at what we need to do to wire this up on our front end. We are in our ChannelVault component. More specifically, we're in the Alpine component, where we're going to start interacting with Echo to listen on the channel which we're broadcasting our messages from the back end. And to do that, we're going to set our channel property by saying this.channel equals Echo.channel And then we want to use the channel name, the same channel name which we are dispatching the messages to from our back end. In this case, we're going to use channels. And we're going to directly use Blade here to access our channel ID. So here we are back in the front end, and we have our Network tab enabled.

And we're going to directly use Blade here to access our channel ID. So here we are back in the front end, and we have our Network tab enabled. Scope to WebSockets. So here we can see our connection to Reaver. We've got connection established when the page first loads. We're asking Echo if we can subscribe to channels.1, which in this case is for General. And Reaver is telling us that our subscription has succeeded. So if I go ahead and send a message now, you can also see that we are receiving events through the WebSocket. But nothing is reflected on the front end yet.

through the WebSocket. But nothing is reflected on the front end yet. That's because we've got a little bit more work to do with Echo. Yes, we are now connected to the channel, but we need to tell Echo that we want to listen for some events. So we can do that by saying this.channel.listen, and we want to listen for messageSent. Now this is configurable within Laravel, but by default Laravel will broadcast the message from the back end to the front end using the name of the event that's dispatched from the back end. And I personally think that's a really nice default to use, because it keeps everything

back end. And I personally think that's a really nice default to use, because it keeps everything consistent. When that event is received, we also receive the payload, which we can grab here in the event variable. And all we're going to do at this point is say this.$wire, we're going to access the messages from the $wire object directly from our Livewire component, and we're going to push onto that array the new message. Back now in our front end, if I now say, hey, you can see that I'm receiving that message in real time.

Back now in our front end, if I now say, hey, you can see that I'm receiving that message in real time. Just to prove that that's working, let's take a look at what that looks like with two users communicating at the same time. On the left here, you can see that I'm logged in as me. And on the right, I'm logged in as my colleague, James Brooks. If I send a message to say, hey, James, you can see that James has now received that message from me. And if James replies and says, hey, Joe, I'm now receiving that message in real time. But there is one problem with this.

And if James replies and says, hey, Joe, I'm now receiving that message in real time. But there is one problem with this. We're broadcasting these messages on a public channel, which means users who don't have access to these channels and are authorized to access these channels can still receive those messages and see our communication between each other, which is not ideal. We really want to lock those channels down and make sure only the users that should have access do have access. And we're going to tackle that in the next lesson.