All right, so it's Monday morning at the time of this recording. I have a cup of coffee next to me. We're going to get started clearing out some of these issues and PRs, just going through what's new in the last handful of days since I've been off. We should consider configuring a queue driver for Laravel Scout. Any recommendations? Okay, so you can run any of your Scout operations through a queue, and I'll show you. Laravel Docs, Scout, right here, and if we want to queue it. All right, so right here we can go into config/scout and set the queue option to true. So if we were to do that, where is it? You'll see that by default it is set to false, and if we check our .env file, yeah, we're not referencing that anywhere, which means everything's going to be done as part of that current process. But if you want, you can take sometimes those lengthy operations and just throw it into a queue instead. So why don't we add support for

going to be done as part of that current process. But if you want, you can take sometimes those lengthy operations and just throw it into a queue instead. So why don't we add support for this? We'll go back to .env, paste that in, and we'll set that to true. Next, we need to make sure that we do have a queue driver set up. So once again, by default we're using sync, which just means it's all running inline, so to speak. Now we could use any of these, like Redis, SQS. I think in many cases a lot of people frown upon this, but I don't think you need to frown upon it for a very, very long time. I think the database driver is actually a surprisingly good choice when you're getting started. Now clearly, if your form has millions and millions of users and stuff like that, you should switch to something, probably Redis is what I would reach for personally. But in the massive majority of cases, you're just not dealing with the numbers like that, in which case the

you should switch to something, probably Redis is what I would reach for personally. But in the massive majority of cases, you're just not dealing with the numbers like that, in which case the database driver, which just means you're going to update a record in a database, we will check to see if that table has been updated, and then we will run the job. It's a really good choice, and it's easy and works everywhere. So why don't we see what that would look like? And now real quick, I just realized I'm in environment.example, we want .env. Okay, so we'll paste that in here, and then we want our QDriver. So we're going to set that to database. Now if you've ever used the database driver before, you do have to run a migration. So let's see, driver prerequisites. Yeah, so if you're going to use the database QDriver, you need a database table to hold those jobs, right? So Laravel includes one out of the box. We can run php artisan queue:table. Let's do that now.

so if you're going to use the database QDriver, you need a database table to hold those jobs, right? So Laravel includes one out of the box. We can run php artisan queue:table. Let's do that now. php artisan. Well, first, let's review the help. Create a migration for the QJobDatabaseTables. Okay. All right. So now if you want to take a look at that real quick before we run it, migrations/create_jobs_table.php. All right, so we're going to have the queueName, which we'll, of course, add an index to since Laravel will need to quickly find those records. We're going to have a payload, the number of attempts that we have tried to execute that job, because remember, what if you have a job that errors out? Well, if you don't set the number of attempts, the number of maximum attempts, it's just going to run that job over and over and over and blow up your system. So it's important to say, give it a total of three shots, and if it fails,

this would represent some kind of task that takes a long amount of time, whether you're sending email or you're processing some data or audio or video, anything you want to put there. For now, we're just going to log something to prove that it has taken effect. So now let's boot up php artisan tinker, and we'll dispatch a new PerformLongRunningThing, and maybe we want to delay it. So maybe, like, in three minutes after you sign up, we're going to run this task. So I could say Carbon::now(), basically, addMinutes(3). Okay. So do note, behind the scenes, Tinker is going to alias that class, but if we now switch to SQLPro and give that a refresh, hmm, did that not run? Oh, there it goes. Okay. Anyways, if we take a look, we're running on the default queue. We have information about the job or the command that we're running, as well as when it should run and when it should be delayed, and at the moment, it has been attempted zero times. So I'm just

information about the job or the command that we're running, as well as when it should run and when it should be delayed, and at the moment, it has been attempted zero times. So I'm just going to pause and wait for a couple minutes, and we'll see if this executes. To start, though, we'll go to laravel.log, and you can see this file is empty. Okay. Let's wait a couple minutes. But now we've waited enough time, and we still don't see anything here, and if we come back, the job is still there. Now, this is a really common pitfall people run into. They create a job, they dispatch it, they expect it to run, and it never runs. So what is the issue here? Well, remember, this is where workers come into play. Think of a worker as, like, a little employee, a worker bee, who checks in every single minute, and he says, any jobs for me to do, boss? And if there are no jobs here, then it's good. I'll come back in a minute and check again. So the next

a worker bee, who checks in every single minute, and he says, any jobs for me to do, boss? And if there are no jobs here, then it's good. I'll come back in a minute and check again. So the next minute, the employee comes in. Any jobs for me to do? Yes, I have this job for you to do. Go ahead and execute it. That's how it works. The worker just checks in over and over. And even on top of that, for large projects, if one worker, one employee isn't enough, and you want multiple people checking in for work because the jobs are coming in faster than that one worker can deal with, then you add as many workers as you need to. That's how this works. So in our case, we have a job ready to go, and no worker has checked in to see if they have work to do. Let's go ahead and run php artisan queue:work. Now, on your production server, of course, this would be a long-standing process. Okay, so notice here it found, yeah, there's one job in

Let's go ahead and run php artisan queue:work. Now, on your production server, of course, this would be a long-standing process. Okay, so notice here it found, yeah, there's one job in the queue. I'm going to go ahead and execute that. So if I give this a refresh, it's gone. The worker checked in, it saw there was one job to do, it knocked it out. So if we switch back to Visual Studio Code, hmm, let's give that a minute. There it is. Just had to refresh. We now have executed the job. That's how this works. Okay, so I will go ahead and delete that, and let's see how we're doing. We'll go to GitHub. Now, in this case, yes, we created the migration. However, yeah, it's true. We're not committing the .env file. Now here, yeah, see, your local and your production settings will differ. So it's very possible, locally, you do just want to do everything in sync. You don't want to deal with a database driver and

your local and your production settings will differ. So it's very possible, locally, you do just want to do everything in sync. You don't want to deal with a database driver and running a queue worker, but on production, you would. So this would be a situation where you would update the documentation. However, let's update Scout. We do want that to run on a queue. So I'll say right there, yes, we want Scout to use a queue. However, at the moment, we're just using a sync queue. And on production, you would change that to database, or if your app grows, maybe switch over to something like Redis. All right, so let's come back. This looks good to me. So let's go ahead, and we'll close out issue number 128. Use Scout queues. And this resolves 128. For production, set queue driver to database. And again, we would update the real documentation because nobody's actually going to read that message who will install our project.