NEW in Laravel 13.6: Debounced Queue Jobs

Hello guys, this week's new version Laravel 13.6 introduced a new feature called debounced cued jobs. Here's a tweet by Taylor and here's the syntax. So on the job you can define debounce for 30 seconds or other parameter and this is the description. So what exactly is the use case and how does it work? Let me show you that in a demo project. The short description is in the docs. In the case of the same job is dispatched many times for whatever reason in a short window only the latest dispatch actually executes. So imagine this scenario filament admin panel or any laravel project in fact and you have bulk operation on some kind of orders for example and each order has an observer to calculate the data for related records for example summary for specific customer of that record. So for example 10 records and then there's a table customers that calculates lifetime value of that customer. So for example if you choose many orders and use bulk actions mark as shipped which should recalculate the lifetime value of that customer then that bulk operation performs this for each of records order update. Then on that order update we have observer class order observer and then inside of that order observer we have dispatch of the job class and I deliberately have two separate job classes here with debounce and without debounce of the Q job but both are doing the same thing rebuilt customer stats basically recalculating the customer lifetime value and stuff like that but let's imagine it's a heavy operation that's why it has sleep for 2 seconds. So this is the actual problem. Multiple orders are updated. Then multiple observers are fired. Each observer fires a job. Although actually we need to calculate that stats for that customer for the same customer only once on the last order update, not on all of them individually. And if each operation is heavy like in this case sleep for two seconds is a fake example then you would definitely want to dispatch Q job only once at the end instead of individually for all of them. Let me demonstrate that in action before and after. So in thev file I have one parameter order the bounce enabled true or false. Let's have false and then that parameter is used in the config in the observer to decide which class to call. And if we have that as false let's launch Q work. I will use database driver in this case. So no jobs in the queue yet. Also I will launch Laravel log tail this command. So Laravel log is empty and that observer class will log info for the observer. And look what happens if I have 10 orders bulk actions mark as shipped which is successful. Look what happens in the terminal. So this is Q work each happens in two seconds separately. So it will launch 10 Q jobs for 10 orders and this is specifically in the log. So it's calculating the same lifetime value 10 times instead of one time and it is done in 20 seconds. Now let's have a different parameter in ENV. So let's change that to true. And then in this Q job we have this debounce for 10 seconds. And that Q job class is just extending the same typical not the bounced Q job. So it's basically doing the same thing with this parameter on top. And now I relaunched Q work and the queue is empty again. And I will take another set of orders. So page number two again 10 orders mark as shipped. Confirm and see what happens in the queue. We don't have anything yet. And in the logs as you can see 10 are already dispatched and only in 10 seconds as you can see we have rebuilt the lifetime value and in this case all 10 jobs were actually dispatched but look at the timing 1.15 milliseconds and only the last one was 2 seconds which means that the last time only it was actually executed. to understand how that actually works under the hood and what can you also customize. You can read the official pull request by Matthew. So thank you Matthew for contributing that to Laravel framework and this is how it works and comparison with should be unique and also the usage and there are a few more things. So you can add max weight, you can add more stuff also cache can be customized like this and a few more notes and see how many people actually were waiting for this contribution to be merged into the framework. So great new feature in the newest Laravel 13.6 six to basically group similar cued job into one job which would be much faster to execute for global summary of a set of jobs. And in my opinion, in my experience, Laravel cues is a very needed topic to learn if you want to become a senior developer with practical usage of various cues drivers and optimization of how Q jobs work. Because typically in web projects the layer of visual website is just the layer to like login and register and then the user actually dispatches some operation. That operation may be AI related these days or it may be just deployment like Laravel forge or cloud. You can imagine how much stuff is happening on those websites on the back end in the queue. So yeah, my kind of career advice is to learn Q's specifically on a deeper level to have access to more serious projects. And if you want to practice with Q's kind of from the beginning, I have recently updated course on Laravel Daily which is textbased course. So you can choose which topics you want to dive into. And also there's a bonus new AI skill Laravel daily cues audit. So you can audit your project and your cues whether they are efficient and what needs to be changed according to your AI agent. So this could be the result. So if you want to get access to that skill and the full course the link will be in the description below for premium members of Laravel Daily. So what do you think about this new feature? Will you have a use case for that or have you had a workaround earlier for this problem? Let's discuss all of that in the comments below. That's it for this time and see you guys in other videos.