Let's go ahead and pull together a really simple example and we'll look at how this allows us to move over from all that clutter in our handle method to some really simple middleware. Okay, so we're going to go ahead and use the example of a podcast. So let's go ahead and make out a model called podcast. And alongside this, let's also go ahead and make out a job to process a podcast.

Okay, so over to the create podcast table, we're going to keep this really simple to save some time. And I'm just going to include one column on here, which is just going to be a timestamp. This is going to be when this is processed and this will be nullable if it hasn't been processed. Okay, let's go ahead and run our migrations here.

And once we're done, let's go straight over to our web routes and start to create this out. So we'll say process podcast dispatch, and let's go ahead and find a podcast by its ID and pass that into the job. We don't have one at the moment, so let's just manually create one out in the database since we are just making this really simple. And let's just fill in the created at and update to that date.

Okay, so we're passing this podcast into this process podcast job. Let's accept this in, let's create out a public property in here with that podcast. And then down in handle, we want to go ahead and update this once this is finished. So we will process the podcast here, in which case we're going to go ahead and log out processed just as an example.

And then we want to take the podcast and go ahead and update it. So let's update it or touch the timestamp on that column if we set that as a date to the processed at date. And we'll just set that to the current date and time. Okay, so just before we forget, let's come over to the podcast model and we'll just set guarded to false just so we can fill in them columns.

And we should be good. Okay, so let's go ahead and run our queue. So we'll just use queue work here. And what should now happen is that will get processed.

And if we add up to the database, sure enough, the processed gets filled with the current date and time. Now, let's imagine that in some other process somewhere, perhaps in an admin panel, we process this podcast manually. But this is still in the queue waiting to run. Well, we don't want to process this again.

So we want some kind of protection inside of the job to not process this again. If it's already been processed for a podcast, you might be encoding some audio, which is pretty intensive. So you don't want this to run if it doesn't need to be run. So how do we do this?

Well, let's go back over to our job here. And before this skip middleware was introduced, we would probably do something like this. We would say something like this podcast is processed. And we'll create that helper method in a minute.

Then we're just going to do an early return. And we're not going to get to the point where we process this. So over in the podcast model, let's create our is processed method. And let's go ahead and fill in the condition for this.

That's just going to be if the process that column is not null. So let's just say processed at. And there we go. So now what we'll find is if we run this, it's not going to update this if it's already been processed.

Now, it did just because we need to go ahead and restart our queue. But let's try that one more time. And you'll see that that condition will have taken effect. And it's not updated the date.

Now, this is all great, but we can actually now move this over to the middleware stack of our job using the skip middleware. So let's go ahead and just get rid of this condition altogether. And let's go up to somewhere in our job and create out the middleware method in here,

which has existed for quite a while. So we're going to return the stack of middleware in an array. So this returns an array of middleware. And we're just going to go ahead and use this skip middleware.

So let's pull this in from illuminate queue middleware. And we're going to say when. So the first method when we'll just take in a condition. So we can just say now this podcast is processed.

So this will skip this when the podcast is processed. Reads a lot better, has its own place within the middleware stack of this job. So it makes a lot of sense. Let's go ahead and restart our queue here.

And let's try this one more time. If we head over to the database, you can see that it has had exactly the same effect. So there's a couple of other things that we can do here as well. So if you had a different condition, you can actually use unless as well.

So we want to skip this unless the podcast hasn't been processed. So it just depends on the kind of thing that you're checking. You can use either of these methods, but we also have the ability to pass in a closure here. So we can actually pass an entire closure and go ahead and return the condition.

And this is helpful if we have other conditions in here as well. So for example, if we had some of the condition in here, we wanted to return true explicitly to say that we did want to skip this. So effectively, if you did have a big condition like this or multiple broken up conditions,

they would now be removed from handle and put directly into this middleware stack. So a much better solution for conditionally skipping jobs in your queue by moving these over to use the skip middleware under your middleware method in your jobs.