Playing
02. Installing Reverb
Episodes
01. Broadcasting Basics
02. Private channels
03. Presence channels
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.
18 episodes•1 hr 19 mins•1 year ago
Overview
New to realtime broadcasting in Laravel? This course covers the essentials with plenty of examples along the way, leaving you ready to start adding realtime functionality to any of your Laravel applications.
Broken up into channel types, we’ll cover:
- The basics of installing, configuring and running a Reverb server
- Broadcasting events
- Private channels
- Presence channels
- Client-to-client broadcasting by whispering
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!
Episode discussion
No comments, yet. Be the first!