Laravel 13.4: Better Queue Tools and Stricter Form Requests

Hello lover friends. Today we're looking at Laravel version 13.4 which brings us some nice queue improvements and stricter request validation. Let's go. [music] First up, we've got improvements to the delay attribute. In Laravel, you can delay a job. For example, here with this attribute here where we're saying now this job should be delayed by 30 minutes. And before the delay attribute could be ignored when dispatching a job normally. Laravel was looking at the delay property and not the attribute. This PR fixes that. So, when you now write this on the job classes, you will make sure that this will still be respected and is still working. Thank you, Sumaya. And next, we've got some new queue inspection methods. For working with queues, you already had some nice helper methods. For example, the delayed size one where we could see how many delayed jobs we have. And the same, we also had here for how were pending. And here we also got one here in this example. But the issue here, we just see the only the size. We don't know more about these jobs. And if you really want to know about more of which jobs are being delayed and still pending, then you would have to query them yourself, which is quite a lot of work. So, now we have something new here which is called pending jobs. And if we now run this, we get this whole job back which is, yeah, pretty amazing. You have all information that you need now in order to better debug those jobs. And the same also works with Let's get rid of the first one. Um, this is also for delayed jobs. Let's run this as well. This is currently empty. Let me just trigger my demo artisan command. And now we should still see what we get. So, now we get one back. And yeah, that's pretty cool. For better debugging your queues, we have now delayed jobs, pending jobs, and we also have reserved jobs. Thank you, Jack. And finally, we've got form request strict mode. We have here this reminder recorder which is from an example which I've already shown you in the last video. But this is now a little bit different because now we're using a form request. This store remind. The request is a form request class here where we define if we're authorized to do this request. In this case, true. And then we also define some rules which is, yeah, very nice to clean up your controller and have the central points for um, form objects that you can also use maybe somewhere else if you need to. So, we've defined here title and duration. So, if we go back and let's go to I have this test here. So, we're freezing the second for the test and we're making a post request with the title and the duration. Then we assert the request was okay. And then we also check if we get back the reminder from the database. And if we run this, you can see this is passing all good. But I have here another test which is called it still creates a reminder when unexpected fields are sent. So, what does this mean here? I've added here a new field which is called priority high. So, and if I run this test, this is still passing. So, what happens if from the front end, someone adds, yeah, some new fields which is being sent here to your back end? So, it gets through. The test is still passing. We still have our reminder. This is not a field which I have on my reminder. So, nothing is going to change here on the database. But yeah, this could be an issue depending on how you're going to deal with the data that comes through the front end. Here in this case, we're only using the validated data. So, this means only the fields that we have defined in our rules from the form request are being added here. And this priority field key does never come here into this. But if I would change this, for example, to maybe use the all method which is here a no-go in a controller because, yeah, you don't know what you really get, then this would be an issue. So, yeah, it depends a little bit on how you're dealing with this inside your application. But there's now a way we can make this even a little bit stricter. So, inside my app service provider and in the boot method, we now can call on form request fail on unknown fields. So, this means if there are unknown fields coming in which are not defined inside my form request, remember in our case, let's go back here. We've only defined here the title and duration. So, the fields that you have defined in your rule method here. And if other fields come in, we are going to fail here. And if we go back to our test here, Um, yeah, this one. If I run this now, you can see this is failing. Um, the failure is now for a different thing, but the reason is still because of our priority. And I'm going to show you here. If we're just going to assert that priority is where we're failing here in the session, and let's remove the other stuff here. You should see if I run this that this test will pass now. Yeah, because now we have the session error with the priority because, yeah, that's what we're going to do by defining this in the app service provider. We're treating this as if there's something that we don't want and in our rules here. And there are different ways to define this. We have done this here now inside our app service provider, but you can do this differently on the form request itself. There is also now PHP attribute fail on unknown fields which is the same. And there's also a property which you can also define inside your class. But I think I would go for this attribute or make this even globally working for every form request by defining this inside the app service provider. Thank you, Nurullah. Thanks to all the contributors making Laravel better with every release like this one. So, if this was helpful, please hit the like and subscribe button and see you the next time. Bye.