Why does laravel-stripe-webhooks package recommend making job classes queueable?

Question

From the spatie/laravel-stripe-webhooks package's documentation:

We highly recommend that you make this job queueable, because this will minimize the response time of the webhook requests. This allows you to handle more stripe webhook requests and avoid timeouts.

And this is the example they give:

class HandleChargeableSource implements ShouldQueue
{
    use InteractsWithQueue, Queueable, SerializesModels;

    /** @var \Spatie\WebhookClient\Models\WebhookCall */
    public $webhookCall;

    public function __construct(WebhookCall $webhookCall)
    {
        $this->webhookCall = $webhookCall;
    }

    public function handle()
    {
        // do your work here

        // you can access the payload of the webhook call with `$this->webhookCall->payload`
    }
}

As per my understanding, this is how this package works:

1. A webhook event is posted by Stripe to the endpoint I set up, which calls \Spatie\StripeWebhooks\StripeWebhooksController's __invoke method.
2. The package dispatches a job.
3. Then the job itself being queuable means it will be pushed another time to the queue.

I would very much appreciate an explanation on why I should make the job itself queuable. As far as I know, just the controller dispatching the job should be enough to minimize the response time of the webhook requests.

Am I missing something here? Is the queue not being used twice for the same webhook event?

Thank you in advance for you answers.

Answer 1

EDIT: it is indeed not necessary to make the jobs queueable since the incoming webhook requests are already queued. The readme of this package seems out of date. They added a package called spatie/laravel-webhook-client in 2021 which is responsible for queueing incoming webhooks. They did not update the readme at that time.

---

Your understanding of the package workings is mostly correct. When the webhook endpoint is called, it will dispatch a ProcessWebhookJob on its own queue. This job in turn will check which events happend and dispatch jobs you registered for those events.

If you don't define your own jobs as being queueable, they will be processed in the same process as the ProcessWebhook Job. Which may cause processing delays and even timeouts if your jobs take a longer time to complete, or there are many events to handle.

Thus, it makes sense to define your own jobs as queueable to push them onto a queue when dispatched. This will free up the ProcessWebhook Job to only dispatch jobs, not do processing.