Laravel Queue Jobs: Avoid Failures by Double-Checking Everything

One free lesson from my course called "Queues in Laravel", with examples of why/how you should be careful about the code inside of any queued job.
Full course "Queues in Laravel": laraveldaily.t...
Or, yearly membership to get ALL courses: laraveldaily.t...
- - - - -
Support the channel by checking out our products:
- Try our Laravel QuickAdminPanel: bit.ly/quickad...
- Enroll in my Laravel courses: laraveldaily.t...
- Purchase my Livewire Kit: livewirekit.com
- Subscribe to my weekly newsletter: bit.ly/laravel-...

[@ward7576]

It is always better that you send a `now()` timestamp to the job itself (through dispatch method params or however you queue the job) instead of getting the timestamp from `now()` in the job due to the same fact that you don't know when the job will be executed therefore timestamp will no be correct.

[@Voolh]

I'am using transactions in this case.

[@nabeelyousafpasha]

Do your course have Supervisor, Worker, Cache elaborated?
Respect from Pakistan 🇵🇰

[@LaravelDaily]

Supervisor: yes, last lesson I explain what Supervisor is and what it does and mention the docs on how to configure it
Worker: well yes, queue:work is a worker, not sure how to elaborate on this more
Cache: this is outside of Queues topics, what about Cache?

[@zengine2743]

Ty for the lessons, but if possible I really want to see how use Laravel octane, thank you

[@LaravelDaily]

I haven't used Octane myself, so can't show it

[@Raftor74]

In my opinion, passing an ID instead of a whole model is a better practice. First, we don't need to worry about serializing the models correctly. Some connections have message size limits. Secondly, everything explicit is better than implicit. Receiving data manually inside the job, we control this process and select only the data that we really need. We also receive only up-to-date data.

[@shoppexsrb]

If you have millions of jobs, then this equals to millions of more requests to the database.

[@Raftor74]

​@@shoppexsrb millions of jobs is already a highload scenario. I am not claiming that the above solution is the only correct one, I am simply arguing for it. If it is necessary to receive data from many places, then we can simply cache it.

[@guillermocen]

Greetings from Venezuela, could you make a video explaining how to find and read the API of the laravel documentation to learn and memorize all the available methods and chain them, every time I check the API documentation I feel lost. Thanks

[@LaravelDaily]

There's no one way to explain it or to make a video. It's just years of practice on various projects, reading a lot of code written by others, and then you memorize things, or at least know where to look for them.

[@ABHISHEKKUMAR-ne3rk]

How we use custom queue..

[@del4nath]

I love your video. Always great Laravel content. Maybe one day soon you could approach scaling Laravel, DDD, HMVC or something similar. How would recommend scaling a Laravel application possibly with module and an event bus?

[@LaravelDaily]

Those are very very individual, and it would take a lot of time for me to explain or review such project. For now, I'm sticking to more "mass audience" topics which are not advanced level. But maybe eventually I'll get to those you mentioned.

[@sureshramani4927]

How to deal with Queue in Large Scale Application ?
Can we set up a separate server for the queue?

[@LaravelDaily]

Yes, you can configure Redis system and provide the credentials to Redis in config/queue.php

[@NotBeHaris]

Awesome

[@abdulrehmandar8541]

real time notification when queue completes?

[@LaravelDaily]

I have a lesson inside the course about progress watching.

[@abdulrehmandar8541]

@@LaravelDaily will you publish it on youtube?

[@LaravelDaily]

Yes, in a few days

[@Stoney_Eagle]

I abuse this system I think 😂😂
I dispatch almost a million jobs at once sometimes. It takes 3 days to process with 10 workers 🤯