There are three Laravel ecosystem tools we're going to use to unlock the real-time capabilities of our application. Laravel itself will dispatch events from the backend for the frontend to consume, and on the frontend we will use Echo, which listens for those events and exposes hooks, allowing us to act on them as they happen. Finally, Laravel Reverb provides the websocket-powered communication conduit between the backend and frontend of our application. Laravel will dispatch the event to Reverb. Reverb will then deliver the event to the relevant connected client, and the client collects the event via Echo so that we can act on it as we wish.

Reverb will then deliver the event to the relevant connected client, and the client collects the event via Echo so that we can act on it as we wish. All of these tools may be installed by enabling broadcasting in our application. Let's take a look. We can enable broadcasting in our application via php artisan. That's as simple as php artisan install broadcasting. It's going to go ahead and do a few things which we'll look at in some more detail in just a second, but one of the first things it's going to ask us if we want to do is install Reverb. Of course, we're going to say yes.

Reverb. Of course, we're going to say yes. That's going to go ahead and add Reverb to our composer.json and immediately install that for us so it's available to us as soon as this command has finished. It's also going to run Reverb's internal install command, which will publish configuration files and set environment variables to some sensible defaults for us. Now it's going to ask us if we want to install and build the node dependencies required for broadcasting. What that's referring to here is Echo, so we're going to go ahead and install that. In a similar fashion to Reverb itself, it's going to go ahead and add that to our node

What that's referring to here is Echo, so we're going to go ahead and install that. In a similar fashion to Reverb itself, it's going to go ahead and add that to our node dependencies and install those and rebuild our application for us. Once this command has completed, everything is in place to allow us to integrate broadcasting into our application, but let's take a look at what's actually happened behind the scenes. Here we are in our source control panel, so we can see actually the files that have changed or been added to our application since we ran the install command. First, as you might expect, you can see that Laravel Reverb has been added to our composer.json file and our lock file updated to indicate that it's been installed. In a similar fashion, our package.json file has been updated with Laravel Echo and PusherJS,

file and our package-lock.json file updated to indicate that it's been installed. In a similar fashion, our package.json file has been updated with Laravel Echo and PusherJS, which Echo uses under the hood. And again, our package-lock.json file has been updated to show that those dependencies have indeed been installed. Our app/bootstrap.php file has also been updated to include our channels.php file. We can also see that that's been published down here, so let's jump in and have a look at what this is actually doing. Laravel's broadcasting works on the concept of channels. Laravel will dispatch an event to a particular channel, and on our front end we will listen

Laravel's broadcasting works on the concept of channels. Laravel will dispatch an event to a particular channel, and on our front end we will listen on that channel in order to receive the event. This allows us to determine who should and shouldn't receive certain events. Channels can be private or they can be public. Private channels require authorization, and that's what the channels.php routes file is doing. We can then define a channel and determine whether the current authenticated user should have access to that channel. When this file is published, we are given this example.

have access to that channel. When this file is published, we are given this example. You can see here, broadcast channel, and our channel name is app.models.user, and then this wildcard placeholder ID. That ID is going to be passed through to us in the function body, and in this callback we're just going to simply return a boolean value to determine whether or not that User should be authorized. If the current User ID matches the ID that's been passed through to us from the channel, that User will be authorized, and we're going to return a true. What happens behind the scenes when we return true from here is that Laravel will actually

that User will be authorized, and we're going to return true. What happens behind the scenes when we return true from here is that Laravel will actually return an authorization token, which can be passed via echo to Reverb, and Reverb will then use that to determine whether the User should be able to access the channel or not. We'll see a little bit more detail on that later on. You can also see here that our broadcasting.php file has been published, along with our reverb.php config file. These can remain in default for now, we don't need to change any values in here. Finally, our entry point into the JavaScript of our application has been updated to include echo, and echo.js has also been published.

Finally, our entry point into the JavaScript of our application has been updated to include echo, and echo.js has also been published. This is going to set up a default echo installation for us. As we know, our front-end dependencies have been updated and rebuilt for us, so really the only thing left to do here is to start the Reverb server. If I reopen my terminal, we can start Reverb with php artisan reverb:start. That will go ahead and start the server on port 8080, which is the default. With the server now running, and with our assets already built to listen to the server on this port, we should be able to jump over to our application and see whether we're connected. Let's take a look.

on this port, we should be able to jump over to our application and see whether we're connected. Let's take a look. Here we are back in our application, and this time I have the network inspector open and scoped specifically to WebSockets. Here we can see Echo has asked Reverb to connect to the server, and Reverb has returned a response to say, yes, you can connect, and that connection is now established. The front-end of our application and the back-end of our application are now free to send data between each other in real-time. We can see that that's already happening. Echo will actually periodically send pings to the server to make sure the server connection

We can see that that's already happening. Echo will actually periodically send pings to the server to make sure the server connection is still active, and when Reverb receives that request, it will send a pong message back to let Echo know that it was still connected. So our app isn't doing anything in real-time just yet, but we now have the foundations in place to really be able to make this application come to life.