Realtime with Laravel Reverb
Playing
08. Queued 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 might be getting ahead of ourselves here, but let's go back to something that we looked at earlier.
00:04
And that's the difference between shouldBroadcast and shouldBroadcastNow. And we know that shouldBroadcastNow will immediately broadcast an event to your WebSocket server.
00:15
But shouldBroadcast, by default, will put this into your queue. So let's go ahead and set up some really basic queues and see how this works. Of course, the benefit to queuing
00:25
is that you're not sending or running too many events, particularly if you have any logic in there all in one go. And if you have a really high traffic application, queuing these can help.
00:35
OK, so we're going to head over to our example that we created earlier. And we're going to change this over to use shouldBroadcast instead.
00:44
Let's go back over to our dashboard and change this over to our example event. Finally, we'll just head over to our web routes and we'll bring back the example that we created earlier.
00:55
And there we go. OK, so if we head over and we dispatch this, sure enough, nothing comes through. This is now being put into our queue.
01:03
Now, by default within Laravel, queues are stored or jobs are stored inside of the database. You can see that this event that we are now trying to broadcast has been added to the database.
01:14
Let's go ahead and just get rid of this for now. And we'll go over and start our queue. Now, if you're not familiar with queues over in our EMV file, you can see that by default, the queue connection is database.
01:25
Everything's already set up for you. So we don't need to run this or migrate anything. We can just run our queue now and see this get processed. OK, so on the command line, we're
01:34
going to run php artisan queue work. And that's going to hang. And it's going to look for any jobs in the default queue. We can also broadcast to specific queues,
01:45
which we'll look at in a second. But for now, we're just running on the default queue. OK, so now that we've done that, if we head over and we run this, what we're not going to see
01:54
is this instantly appear. This is going to be processed within the queue, which takes some time. So let's go over and run this.
02:00
And you can see that nothing comes through. We wait a couple of seconds, and then that was broadcast. So what's actually happened behind the scenes is this job, which has now disappeared, got processed,
02:11
and it sent it off. So again, a really good option if you have loads of data that you want to send and you want to queue this up rather than run it straight away.
02:19
If we head over to the terminal, you can see that, sure enough, the example event that we had queued has run and then completed successfully. Now, let's just take a look at what
02:29
happens if we want to put this on a separate queue. You might have an application that has a queue for one thing and a queue for specifically chat messages, for example. Well, this is really easy.
02:41
What we can do is, inside of the event, specify which queue this should run on. Let's go ahead and just create out a queue called chat and push this specifically to that queue.
02:52
Let's go over to the terminal and, again, run phpArtisanQueueWork. If we have a look at this, we can define multiple queues. We'd normally use something like Laravel Horizon for this.
03:02
Let's just have a look at the options that we've got here. And you can see that we can define which queue that we want to run. So in our case, we're going to go ahead and say queue
03:12
and chat. And that's now listening on the chat queue. And now, when we go over and run this, we should see that get processed on that specific queue.
03:23
So if you're already making use of queues and you want to queue any of the events that you're broadcasting to your server, it's really easy to do so.
03:31
If you need to dynamically build up this queue name, you can also go ahead and provide a method. So much like the other methods that we have, like broadcastWith, you just need to define out
03:41
a broadcastQueue method and return a string from this with the queue name. We'll go ahead and get rid of this property. And that is how we queue broadcasted notifications.

Episode summary

In this episode, we're taking a closer look at how queueing works with broadcasted events in Laravel. We start off by revisiting the difference between shouldBroadcastNow (which fires things off immediately) and shouldBroadcast (which puts the event onto a queue to be handled later). This is super useful if your app is getting lots of events and you don't want to overload your server.

We'll walk through setting up a basic queue just to demonstrate how events are queued by default in Laravel. The database connection is already set up, so all we need to do is fire up the queue worker with a simple Artisan command. You'll see in real-time how events go into the queue and get processed a few seconds later, instead of immediately.

Then, we look at how you can push events to a specific queue (like a special 'chat' queue for chat messages). It's just a matter of configuring the event itself, and Laravel takes care of the rest. Running multiple queues or even targeting them separately is no problem, and we touch on using tools like Laravel Horizon for this as well.

Finally, you'll see how to dynamically determine the queue name in your event, using the broadcastQueue method. That gives you a ton of flexibility for more complex applications.

So, in this episode, you'll learn all about broadcasting queued events, organizing queues, and making sure your real-time features stay snappy and scalable!

Episode discussion

No comments, yet. Be the first!