Realtime with Laravel Reverb
Playing
02. Installing Reverb

Episodes

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

Transcript

00:00
The first thing that we'll need to do is get broadcasting set up within Laravel,
00:05
get Laravel Reverb installed as well, and run our server. In this episode, we'll also take a look around what this actually does to a fresh application, and we'll look at some of the config that Reverb gives us as well. So if you're following along, we're going to go ahead and create out a new project here.
00:23
Let's call this Real-Time Laravel Basics, and we're going to choose the Laravel Breeze Starter Kit with Blade and Alpine. We're not going to tie this down to any specific starter kit just yet. We'll just stick with Blade and some really simple JavaScript. OK, let's run through these options and just wait for this to prompt us for a database,
00:43
and let's just choose MySQL here and go ahead and create that out. OK, so once our project is created and we have a fresh Laravel app, let's just take a look around this because it slightly differs from previous versions of Laravel. In previous versions of Laravel, it's assumed that you are going to use Real-Time,
01:01
and Laravel Echo, which we're going to cover soon, will have already been installed and included inside of your JavaScript directory. If we take a look at App, which just requires in Bootstrap and boots Alpine up, and Bootstrap, you can see that there's nothing about Real-Time in here at all.
01:19
The same thing for your EMV file. So if we just open that up and we search for reverb, of course, we don't have anything. If we look at broadcast connection here, you can see that this is currently set to log. So any of the events that we create inside of an application and we broadcast to a WebSocket server
01:38
will just be logged out in our Laravel log file. So at the moment, a fresh Laravel installation assumes nothing about how you're going to be broadcasting events in Real-Time. That's where we want to go ahead and install Laravel's broadcasting functionality. Let's take a look at this, because this is going to then prompt us to install Laravel Reverb
01:58
if we want to. Okay, so to get broadcasting set up within our project, we're going to go ahead and use the install set of commands, and we're going to install broadcasting. So it's going to make a few changes to our application, which we'll have a look at in just a second. Okay, so when we run this command, we get a broadcasting configuration file published,
02:20
we get a channel's root file published, which of course we'll be taking a look at, and we get prompted, do we want to install Laravel Reverb? Now, when you're working with Real-Time in Laravel, you can choose any Real-Time server. It doesn't matter. Anything that is supported by Laravel, you can choose. You can choose a third
02:38
party server if you want to do that, you'll probably have to pay for, or you can pull something in locally like Sockety, which is another WebSocket server. We're of course covering Reverb, so we're going to go ahead and say that we do want to install it. So that's going to pull in the Reverb package, and it's going to also prompt us, do we want to install the node dependencies?
02:59
That's going to pull in Laravel Echo and anything else that we need to get this working. So now that we've said yes to both of them commands, let's just take a look at how our application has changed. So if we open up our EMV file, not our example EMV file, you can see that the broadcast connection has already changed to Reverb. We'll take a look at where this is
03:20
referenced in our config in just a second, but if we search for Reverb inside of our EMV file, you can see that it's added some basic sensible defaults for Reverb. Now, Reverb connections or apps need an app ID, which we'll take a look at in a second, a key and a secret. So really, these are only important when we go into a production environment, because of course,
03:43
you're going to want to protect your WebSocket server from anyone being able to push to it. The only thing that's probably worthwhile changing on a local development environment is the host. So I'm using Laravel Herd, so the project that we've created is real-time Laravel Basics, and using Laravel Herd, this will give us a .test domain. So that is the only thing we're going to
04:06
change while we're working locally, and even if we don't, it shouldn't really matter. Okay, so we've also got some of these configuration options exposed to Vite. So when we reference any of these within JavaScript, these will now be available. Let's take a look at that now, because you can see here that an echo.js file has also been published in our JavaScript directory,
04:30
which is referenced at the bottom of Bootstrap. Now, let's open this up and have a look. Okay, so Laravel Echo is the client side of your real-time functionality. So when we push an event inside of Laravel internally using an event class, this will push all of our event data to our reverb server, which we're going to start up in a second. Laravel Echo will allow us to detect
04:56
if an event has been broadcast from our reverb server, and we can pick this up in the client side. Don't worry if this doesn't make too much sense at the moment, we're going to be diving into Echo and receiving events later, but all of them configuration items that we saw in EMV are all being referenced here, so everything maps up and we know that we're connecting to the right
05:16
server. Okay, so another thing that's happened here, if we just head over to our config directory, we'll have a reverb config file that's been published. Now again, when you're working locally and just learning about real-time in Laravel, you don't really need to worry too much about this, but let's just head down and have a look at our reverb servers section. So we're
05:37
just running one reverb server here, again this references all of them values that we have in our EMV file, so the host that this is running on, the port that this is running on, and really a lot of this stuff you're going to configure in production when you want to start to scale up and all that kind of stuff. So let's go down, because we've seen our server, and let's look at our applications.
06:00
So we can have multiple reverb apps, so if for example we had a reverb server that was dealing with two separate applications we were building, we can do that as well. This is very convenient, means that we don't have to run reverb multiple times, and we can have two apps in here. And again all of this stuff comes from our config, we can choose our allowed origins, by default this is
06:23
an asterisk, which means that this is going to allow all origins, but of course in a production environment you're perhaps just going to want to allow these to only come from a certain origin. Okay so now that we've looked at our config, and we have looked at the EMV changes, let's go into our roots directory, and we'll see that a channels file has been published. So these channels we're
06:47
going to be defining up throughout the course, depending on where we're listening to, and there's multiple ways that we can define and return from channels. Laravel gives us a default here, this is a private channel which will authenticate the user, and make sure that they are allowed to access that channel. Again don't worry if this doesn't make too much sense just yet, we're going to be covering
07:09
that later. Okay now that we know where everything is, how do we start up our reverb server? Well we do that from the command line. So let's go ahead and run php artisan reverb and start. Now that has now booted up your reverb server, what you can now do is broadcast events from your Laravel application, and your client, which we'll be looking at soon, will listen to these events that have been
07:34
broadcast, and you can do something with the data that you're sending. Now one really important thing about this is that we can actually enable debugging. So if we go ahead and just cancel this off, we can use the debug option, and this is really handy particularly while we're just testing this out, so we can see which data is being sent to our server. When we start to send events these will
07:57
appear here in the command line, so we can see all of the data, which channel this has been pushed on, and when clients connect and disconnect as well. Now you don't want to run this in a production environment, because the amount of data that is coming through will eventually lead to this command crashing. We'll see that in the last section of this course when we look at sending a
08:16
huge amount of events to our reverb server, and we'll probably see it crash. So we're not always going to want to run the debug option, just while we of course are debugging. Okay so now that we have got reverb installed, we've taken a look around the configuration and the channels, let's go over to the next episode and look at defining a channel and broadcasting an event.

Episode summary

In this episode, we kick things off by setting up a new Laravel application specifically for real-time broadcasting using Laravel Reverb. We take you through the process of creating a fresh Laravel project (using the Breeze starter kit with Blade and Alpine, though the starter kit doesn't really matter), and make sure you have broadcasting ready to go.

After initializing the app, we look at how fresh Laravel setups now don't assume real-time is required out of the box—you won't find Echo or Reverb config just sitting there. So, we use Laravel's install command to add broadcasting. You'll see how this command not only creates necessary config files, but also prompts you to install Laravel Reverb itself.

We walk through the changes made by installing Reverb: new entries in your .env file, a dedicated reverb.php config file, and a new channels.php routes file. There's really nothing you have to change for local development, but you get a quick rundown on the config and where all the important settings live—like the app ID, keys, allowed origins, and more. We also touch on the Laravel Echo client, which will pick up server-side broadcasted events later on.

Finally, we learn how to actually start the Reverb server using Artisan, including how to enable debug mode to see what's going on in real time. There's a word of caution not to use debug mode in production because of the volume of data that can crash your server!

By the end of this episode, you'll have Laravel Reverb fully installed, a good sense of the config options, and you'll be ready to move on to defining channels and broadcasting your first events.

Episode discussion

No comments, yet. Be the first!