difference between command and jobs

@bobbybouwmann thanks for the information.

I watched a video here at Laracasts, where Taylor explained that Jobs ( named Commands at the time of the video ) are used when we have to execute a number of correlated tasks whereas commands are used for a single action. More specifically, he gave an example of purchasing a podcast. When a use purchases a podcast a number of tasks have to be executed, such as send a confirmation email, confirm payment etc. From what i understood, jobs are similar to events.

Regarding the differences between commands and jobs, there is a section on the documentation named Scheduling Jobs that confused me.

A job may be scheduled to be run at a specific time.

For example the job is to clean the toilets. A cleaner will execute that job daily at 9am.

An event is different, let's say someone went to the toilets. We will fire an event that someone used the toilets. Then we will need to clean the toilets so we are executing that job again to clean them.

A job can be executed in several ways, from a command, from a controller whatever you'll need. So in the example above the scheduler runs at 9am and fires off the job to clean the toilets.

Isn't the job that you are referring to, an event listener ?

@orest You have the command itself which can be found here: https://laravel.com/docs/7.x/artisan The task scheduler itself is a different topic and can be found here: https://laravel.com/docs/7.x/scheduling

Jobs are not similar to events. An event doesn't perform an action. The listeners perform the action. A job always performs an action. In some cases a listener can even fire off a job. An action tells the system that something happened, while a listener or job actually performs the action.

@bobbybouwmann

My mistake.

I meant that an event listener is similar to a job.

Regarding the events and jobs though, why would you dispatch a job in an event listener ?

If an event happens, for instance a user is registered, then we can have one or more listeners that can take actions.

My understanding was that we use jobs because we can dispatch them wherever we are and jobs can be reusable.

It is a bit confusing though, currently it seems to me like a circle. I've read a lot of other discussions but yet it's not quite clear when to use jobs and when to use event/listeners

So let's say you have a job that calculates the number of experience points of a user and sets that in the database. This is a reusable action inside your code. A job is perfect for this. Let's call this class CalculateExperience

Whenever the user signs up you fire an event that says UserWasRegistered. No you can add a listener called UpdateExperience. This listener itself doesn't have to update the points. It can simply fire the CalculateExperience job in that listener instead of redefining the logic.

Whenever someone likes a certain page, the experience should be updated as well. You can decide to use an event and listener again, but you can also decide to fire off the job in the controller. It depends on the context in this case.

Using jobs vs events really depends on your use case. In some cases, you can use both of them but in smaller application it mostly makes sense to pick one of them and stick to do.

Do you have a use case of your code where you can't decide between a job or an event/listener?

@bobbybouwmann

This example made it a lot more clear! Thanks

No i don't have a use case yet, i was just trying to understand the differences in order to make a proper use of events/listeners and jobs in the future.

Cool! Well, you know where to find us if you have more questions ;)

@bobbybouwmann

I have another question already :D

Instead of creating a job we can just create a simple class or a service and put the logic that we want in there.

I guess that the benefit of a job is that it comes with a set of extra functionalities, such as queues, middlewares, attempts etc.

My question is, if i don't need any of these extra functionalities, is there any disadvantage ( or just a reason ) of using a class/service instead of a job ?

Yeah both solutions work.

I personally like to create separate service classes for this kind of functionality. They also live in the App\Services namespace. These classes can perform simple or complex actions, but remove the complexity in your controllers and other parts of the application. You can for example use a service inside your job class to calculate something. Makes perfect sense ;)

Hi @bobbybouwmann

I do have a use case now.

I want to add a reply to a thread and after i add the reply i want to

1. Increment the replies_counter which is in the threads table
2. Award the user who posted the reply with points
3. Notify the subscribers of the thread that a new reply has been posted

Can i dispatch job addReply which will create a new reply and also handle all the above 3 steps.

Or would it be better to first create the reply

$thread->addReply($reply);
event(new NewReplyWasPostedToThread($this, $reply));

and then fire an event that a new reply has been posted and in the event listener handle all the above 3 steps.

I would first store everything and then fire the event.