Queue Workers in Forge 0:00So let's continue our review of Laravel Forge with a discussion on queues. So let's go into our site here. And if we check out our Forge demo site, and we go into Queue Workers, here's where we can set up a new worker. Now what's really nice about Forge is it automates all of this stuff. So you don't have to worry about setting up Beanstalk. You don't have to worry about using something like Supervisor to make sure that it never falls over. All of that stuff will just be done automatically. Pretty cool. Install Beanstalk Dependency 0:26All of that stuff will just be done automatically. Pretty cool. Now, we could go ahead and start a worker here, but first, let's do a bit of setup. The first step is, if we want to use Beanstalk in our Laravel apps, we need to make sure that we pull in this package here. And you'll find all of these instructions on the Laravel.com webpage. So let's come down, and why don't we just grab 2.1. That should be fine here. So back within my editor, if we browse to composer.json, I will just paste it in right there.So back within my editor, if we browse to composer.json, I will just paste it in right there. Next, on this node, a quick tip. It may be possible that you have composer.lock in your gitignore file. Make sure you remove that, though. It's a good practice to commit this file. Alright, so if I switch back to the terminal and do a git status, let's go ahead and do a composer update to pull in those changes. And now if we do one more, let's add everything and commit with pull-in beanstalk. And push that up. Configure Failed Job Handling 1:14And now if we do one more, let's add everything and commit with pull-in beanstalk. And push that up. So now don't forget, we have quick deploy enabled, so it will pull in those changes and immediately run a composer install. Next though, I want to do one more thing. From time to time, your Q jobs will fail. It's just a fact of life. But if you're not careful, you could end up in a situation where your server is being hit every one or two seconds as it tries to rerun this failed job that will never pass over and over and over.hit every one or two seconds as it tries to rerun this failed job that will never pass over and over and over. So let's do this. We'll say we want to try a total of three times, and then beyond that, let's insert the failed job into a database table so that we can refer to it later if we need to. Luckily, once again, Laravel makes this really easy for us. We can run a single command here, q, and it's called failed table. So that will create the migration for you as well as all of the schema. So now we can do a simple php artisan migrate. Alright, if I do a git status, and we can ignore this because in real life, this would Push a Job to Queue 2:10So now we can do a simple php artisan migrate. Alright, if I do a git status, and we can ignore this because in real life, this would be a local database. We just haven't updated that yet. So let's pull in this, git add, and commit with add failed job table migration. Alright, once again, let's push that up. Next, if we switch back into our little scaffolded project, let's throw something onto the queue. So maybe let's go to a store method. By the way, don't worry about the code here very much. It's automatically scaffolded.By the way, don't worry about the code here very much. It's automatically scaffolded. It's not necessarily what I would recommend to you. Nonetheless though, here you can see we create a task, and then we redirect to the main page. So just for a sample here, let's throw something onto the queue. For now, just bear with me. Let's push a closure onto the queue, and this closure will accept the job. Now that's the first thing you need to know. Whenever you use queues, make sure that you delete the job when you're done. Otherwise, it'll keep firing.Whenever you use queues, make sure that you delete the job when you're done. Otherwise, it'll keep firing. Now in this case, like I said, it's just a little demo here, in which case we will log something. We will do something when task is created. So remember, what we're doing here is we're not going to handle this synchronously. And that's why queues are perfect for long-running tasks. Things like image processing, or sending email, or performing any kind of action that will take longer than you would like. Maybe doing some kind of billing scenario.take longer than you would like. Maybe doing some kind of billing scenario. Instead, you can pass that job off to a worker, and instead get right back to the user as quickly as possible. Now you can reference a class that will be resolved out of the IOC container, or as we're doing here, you can just push a closure onto the queue, which is pretty nice for small, quick, simple stuff. All right, so we have our little task here. Next, if I go into config, queue, here you can see we're using the sync driver. And that means everything just happens synchronously. Switch to Beanstalk Driver 3:54Next, if I go into config, queue, here you can see we're using the sync driver. And that means everything just happens synchronously. But for production, we want to use Beanstalk. Now if we come down to the connections, all of this stuff can remain the same. And believe it or not, because we're using Laravel along with Forge, that's the extent of the configuration that will be required. So let's add both of those files. Commit with add Beanstalk queue support. And push that up. And once again, we have quick deploy turned on, so that'll immediately be reflected in Create and Run Worker 4:25And push that up. And once again, we have quick deploy turned on, so that'll immediately be reflected in our application. So now if we switch back to Forge and go into queue workers, we're going to set up a new worker. Using that Beanstalk connection, the default queue is fine. And here we're saying the maximum length that a task could possibly take should be 60 seconds. That should be more than enough. Next, when it's empty and it keeps firing to see if there are new jobs in the queue, we are waiting 10 seconds each time.Next, when it's empty and it keeps firing to see if there are new jobs in the queue, we are waiting 10 seconds each time. And that should be fine. For a very busy app, you will want to decrease that. And of course, for a small app where you're just not getting that many visitors each day, you might even want to bump this up to maybe every minute or so. Let's keep it at 10. And finally, this is an important one. Set the maximum number of tries. This way, if it fails once, it fails twice, it fails three times, as we will set here,Set the maximum number of tries. This way, if it fails once, it fails twice, it fails three times, as we will set here, it will immediately be marked as failed, and we won't bother trying it again. Alright, so let's start up the worker. And now we can see that Forge is probably using its own queue system to add this job. And none of that happened synchronously, even though, for all intents and purposes, we can't tell the difference. Okay, if we take a look at the status, let's see how the worker is doing. And it's up and running. And like I said, it's making use of a tool called Supervisor, which we've covered at Test and Verify Queue 5:40And it's up and running. And like I said, it's making use of a tool called Supervisor, which we've covered at LayerCast, to ensure that if for any reason this worker stops, it'll immediately be fired back up. But now that's it. So let's try it out. Let's go to our website, and to tasks slash create, create a dummy task here, submit, and now we just fired that job onto the queue, at which point we only logged some information. But here's the cool thing. Imagine if that task was something that required a little bit of time to process.But here's the cool thing. Imagine if that task was something that required a little bit of time to process. Well, because we threw that task onto a queue, it doesn't matter. We can return and provide feedback to the user very, very quickly, with the assurance that in a separate process, we would be handling whatever that job might turn out to be. So now we only need to verify that this did work. Here we are logged into my production server. We can go into App, Storage, Logs, and you'll see a Laravel.log file here. Let's cat that. And there we go.Let's cat that. And there we go. Our job is now complete. So at this point, you understand exactly how to work with Forge. The next step, if you're still a little blurry about queues and workers, is to dig further into many of the various lessons here at LaraCasts.
