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.
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 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.
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?
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?
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.
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
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.
![[LIVE] : ONE ลุมพินี 91 | คู่เอก "คมอาวุธ vs อเล็กเซย์"](http://i.ytimg.com/vi/V0RkEfYFsgM/mqdefault.jpg)
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.
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.
If you have millions of jobs, then this equals to millions of more requests to the database.
@@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.
Ty for the lessons, but if possible I really want to see how use Laravel octane, thank you
I haven't used Octane myself, so can't show it
Do your course have Supervisor, Worker, Cache elaborated?
Respect from Pakistan 🇵🇰
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?
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?
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.
I'am using transactions in this case.
How we use custom queue..
How to deal with Queue in Large Scale Application ?
Can we set up a separate server for the queue?
Yes, you can configure Redis system and provide the credentials to Redis in config/queue.php
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
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.
real time notification when queue completes?
I have a lesson inside the course about progress watching.
@@LaravelDaily will you publish it on youtube?
Yes, in a few days
Awesome
I abuse this system I think 😂😂
I dispatch almost a million jobs at once sometimes. It takes 3 days to process with 10 workers 🤯