Should I (or is it worth it to) use queue's for webhooks?
So I've watched the series on queue's, and they seem like an incredibly useful feature, especially for tasks that can take a long time to process. However, I'm unsure if I should use them for my webhooks for my payments since they are basically instant anyway.
Would love to get some advice on this since I'm sort of on the fence about whether it's really worth it to use them or not. I'm using OmniPay and a few different gateway's that are all functional and at the moment, I just have the request hit the controller directly and it processes very quickly, so I'm not entirely sure if queueing the webhooks is even worth it.
Well, it depends on what you do with the webhook. Are you sending the webhook or are you receiving the webhook?
If you're receiving the webhook, queuing is really important. The reason for this is that you want to let the other party know right away that you received the webhook and that you will process it. Otherwise, the other party might send the webhook again. In general, a webhook sends as little information as possible. For example, only sending the ID of the payment. So the receiving party then needs to retrieve the payment details anyway. You can do this perfectly in a queue.
If you're the sending party it depends a bit. How many calls do you need to send along? How many parties do you notice with the webhook.
Well, you get the idea ;) In my opinion queues are incredibly powerful tools for systems that handle webhooks.
bear in mind that if you queue on any api, you lose the ability to tell the other party that there request succeeded. All you could say is 'we're on it'
So if the input was to say that payment had been taken, ensure you validate the information provided and then queue more complex actions on your side.
@snapey Companies like Mollie actually want you to do this. They just want to deliver the payment ID and you have to handle it from there. The reason they don't send all the info is for security reasons. If they require you to send data right away, I can just post to your webhook and would receive data right away. That doesn't sound secure.
If you don't give a response in a certain time span they will resend the webhook. That's why it's important to handle it later and just acknowledge that you received the payment ID.
@zyxxyzyxz Indeed, you need to put the payment ID in a job on the queue and let the job handle fetching the payment and do any other actions that you need to do. For example, updating the status in the database or sending an email.
We also use Mollie in all Laravel projects and all have the same setup. We never miss a webhook from Mollie and never have performance issues because of this setup ;)
How would I go about writing tests for this method of approaching webhooks? At the moment I have tests that just call the webhook endpoint with the relevant information, but I don't have much experience with queue's. So is it even possible for me to test something like this if the webhook logic is inside a Job class instead?
