bobmulder's avatar

Can the Laravel Queue system be used for communication between two Laravel applications?

Hi there!

I think the subject says it all. I have been reading pretty much about Laravel Queues (as well the book by Mohammed Said). I've been using queues a little.

At this moment I am designing a huge project which I want to build with Laravel. The idea at this moment is to split this project into two applications. However, data should be communicated to each other.

This could be done using webhooks, or a pub/sub pattern (like how it's used for microservices).

So, getting back to my question: are there any creative guys who have ideas how to use the powerfull Laravel Queue system for this? Any things I have not been thinking off? ;)

Thank you in advance!

Bob

0 likes
7 replies
nodenacci's avatar

I have done such an integration. You dispatch a job on to a queue on another server

bobmulder's avatar

Thanks for noticing @mulugu!

Via what way did you dispatch the job, and with kind of payload did you push it? Through an API call (which is basically a webhook)? And I suppose that the payload is not a defined (serialized) Model, but just a plain object payload?

nodenacci's avatar

Yes, the payload is just an array lets say protected $data. Its a good hack. Lets you have 2 servers on the same network (VPC). One is a receiver and another worker. Then the same laravel job on both same only that the handle method implementation is missing on receiver but exists on worker. So on receiver you point your queue host to worker and dispatch there. Amazing thing, I couldnt believe it

martinbean's avatar

@bobmulder I’d say web hooks is the better pattern if you want App A to send some data to App B.

App A can use a queued job itself to dispatch the webhook, and remove the job if App B responds with a successful response (200 OK or something to indicate they received the webhook). If there’s an error, the webhook data goes back into the queue to be attempted again. If it fails x amount of times, you can move it to your failed_jobs table and investigate why the webhook isn’t getting delivered.

nodenacci's avatar

True. But exploiting queues on servers in same VPC is fast and powerful

Snapey's avatar

It all depends if you need a synchronous response?

If the receiving app is always available to service your request then why bother with queues?

The point of queueing between services is to let the receiver deal with the work when it wants, and to not hold up the sender.

The downside is that the sender has no idea if the job was successful, so a reverse channel is also required.

bobmulder's avatar

Thanks for the responses all. While it feels a bit like overkill, I think using queues will help me a lot in future to make my applications secure and fail-proof...

Please or to participate in this conversation.