In the previous video, we talked about how to automate one-off calls to our applications using scheduled jobs, which are similar to kron, but if you need, not a one-off call but a long running process, instead, you're gonna look for forges background processes, formerly known as demons or demons. There are two types of background processes in Forge Q workers and custom processes. So let's start with Q Workers because they are more common.

workers and custom processes. So let's start with Q Workers because they are more common. The most common long running background worker in Laravel applications is the Q worker. And if you're not familiar, Laravel queues basically make it possible for you to push up a encapsulated piece of code or functionality up in a single thing called a job onto a queue. And the idea here is that the original caller, which is usually a user visit,

And the idea here is that the original caller, which is usually a user visit, but sometimes Aron job, doesn't wanna sit around and wait for this thing to happen synchronously. So it pushes it up and says, Hey, you handle this on your own. So Forge conveniently configures your application to use something called database queues outta the box. Which means when you put something on a queue, it actually shows up in a database table called Jobs.

Which means when you put something on a queue, it actually shows up in a database table called Jobs. So we can SSH into our application, which I've done here, and we can run a simple command I've made called app Queue log message. And all it does is just queues up a job that contains this message so that it can log it later. So I say hello, and we come to this database table and now we see that it's in there and you can even dive in and eventually see in the command that it is a instance

and now we see that it's in there and you can even dive in and eventually see in the command that it is a instance of this particular class with this particular data in it. So it's just sitting there, nothing's happening because we don't have a queue worker working on it. So now we want to spin up a queue worker to watch this table and when something arrives, pull it down and execute it. So what we wanna do is go to our site processes, background processes, and create a new background process. And you see there's two tabs.

background processes, and create a new background process. And you see there's two tabs. We're gonna focus on Q Worker right now and we'll look at the custom later. So I say default Q worker, and all of the options here are just configuring what eventually will be this individual call right here, which you're familiar with. If you've ever had to run your own queue worker, the only thing that you need to define

If you've ever had to run your own queue worker, the only thing that you need to define that's not already defined here is which connection you're using, which again is database by default, although you can customize it and configure any of these to eventually build what you wanna do here. And you might be wondering if this is just building something I can do myself from the command line, why even use the background process? And it's because if you do it from the command line,

why even use the background process? And it's because if you do it from the command line, it's just gonna sit there, but then you can't close your terminal. And if you do, all of a sudden it's not gonna work. Or even if you find some way to run it on deploy or something like that, what happens if it gets shut down? What happens if your server restarts whatever else? There's nothing making sure that this is running all the time.

There's nothing making sure that this is running all the time. And that's what these processes do. They allow you to spin up this process, but they also configure something called supervisor to make sure the process keeps running, even if the server restarts or if it shuts down on its own. So let's do it. Let's create background process and we'll go back over to our database and we should, should see this disappear.

and we'll go back over to our database and we should, should see this disappear. So refresh and it's gone. And I did build this so that it uh, let's see, cat storage logs, it, whatever we type gets written down into there. So if we instead wanted to say, uh, let's see PHP current slash artisan, uh, app Q log message and we wanna say goodbye and then we want to take a look at that log,

Q log message and we wanna say goodbye and then we want to take a look at that log, we've now got goodbye in there. So this Q worker is actively working on this for us. So like I said, the way these Q workers work is configuring an instance of supervisor whose responsibility it is to start and restart when needed a specific process on your machine. And the Q worker version is some syntactic sugar on top of the core concept, which is custom processes.

And the Q worker version is some syntactic sugar on top of the core concept, which is custom processes. So custom processes are just like the Q worker, except instead of giving us all these features to build this string right here, it just lets us type it in directly. Everything else about it is the same. And the two most common places where we're gonna wanna do that, uh, in a Laravel application are to run horizon and reverb, which are both long running

that, uh, in a Laravel application are to run horizon and reverb, which are both long running tools that Laravel has. So let's look at how to use background processes to run Horizon. Now I've already got Horizon installed of this application. So really what I need to just run is PHP 8.4 Space Artisan Space Horizon. And that is of course, assuming we're in the right directory.

And that is of course, assuming we're in the right directory. But if I look at this configuration, you can see it automatically fills in the directory for the site I'm in. And it allows me to customize the number of processes and graceful shutdown time if I want. So I can already assume that this will be run from that right directory. And when I create that process, I will be able to see

from that right directory. And when I create that process, I will be able to see that it is running Horizon for me. Oh, if I've given a name horizon. And notice that we always want to take a look at what's in the three dots in Forge. So these three dots give us a couple options, whether it's a Q worker or this custom one, you can view the logs, which is the output of what actually happened there.

you can view the logs, which is the output of what actually happened there. We can view the status, which is just a server level, how's it going, which is what this kind of running badge is interpreted from. We can restart it, start it, stop it, edit the command or delete it. And the same is true for our Horizon log here. Now you've seen us working on this at the site level here, but with a lot of things in Forge,

Now you've seen us working on this at the site level here, but with a lot of things in Forge, you can do them both at the site and the server level. And interestingly, the server level of background processes is not quite the same as the site for very good reason. So if we go to processes, well actually if we go to background processes for the server, you can see that we have that Horizon custom command with a globe next to it.

that we have that Horizon custom command with a globe next to it. Just like when we had the scheduled tasks at the site level showing up at the server level, the queue workers don't show up at the server level, but the custom ones do. So we can do everything with it here that we could in the other one. But let's take a look at what happens when we add a background process at the server level.

But let's take a look at what happens when we add a background process at the server level. It doesn't look quite the same, and it's because some of the assumptions that the site level custom processes can make. For example, the directory you're working in in the user aren't always there at the server level. And the server level things are usually about running things that aren't specific to the site. They're not about running commands on this site about

that aren't specific to the site. They're not about running commands on this site about dependencies that are in here that can be run through artisan commands. They're about running higher level server level systems. And because of that, they can't make the same level of assumptions about where it's working directory is going to be, or even what user is running it. But similarly, if you wanted to, you could say Horizon right here, and you could say PHP 8.4

But similarly, if you wanted to, you could say Horizon right here, and you could say PHP 8.4 and type the whole long directory and it would do the exact same thing. You just have to do a little bit more manually. Also, because of the way we might wanna run server level background processes, there's a few more configuration options here, including what stop signal you're gonna send. In the end though, this is just the same thing. It's just at a different level.

In the end though, this is just the same thing. It's just at a different level.