Support to pick up messages off AQMP like rabbitMq

[kish2011]

We are using the default queue in our app, we want to use rabbitMQ in our app. It would be a good idea if it supports by the core team, though third party lib present.

[mugisham]

We are using the default queue in our app, we want to use rabbitMQ in our app. It would be a good idea if it supports by the core team, though third party lib present.

I agree, currently working in a system with spring boot and Django and Rabbit is helping communicate with these loosely coupled systems.

[michaeldyrynda]

If I recall correctly, there used to be first-party support for Rabbit, but it was removed a long time ago in favour if Redis.

We vyuldashev/laravel-queue-rabbitmq in our app before migrating everything across to Redis. I think it makes more sense for Laravel to niche down and focus support, rather than trying to broadly support everything.

[denizsokullu]

We use rabbitmq in our ecosystem to exchange models and a bunch of other things. I started with https://github.com/vyuldashev/laravel-queue-rabbitmq but then ended up creating an artisan task that runs a subscription consumer loop that takes a message from rabbitmq and dispatches a job to a laravel redis queue. I can explain in more detail if you need help about it. The driver linked in this comment expects the messages in rabbitmq to be a certain format and a lot of the functionality is hardcoded. I found it too rigid to work with.

[mugisham]

But the messages sent in Laravel seem tightly bound to the application. the namespace of the job handler is sent to it which seems like an anti pattern. So if I wanted to send a message to a topic on Rabbit and have another system written in may be Flask or Spring. This is not possible and Flask has Celery. Cant we get a Celery?

[denizsokullu]

Yeah that's what I was trying to explain. The github repository I linked is tightly coupling the message with a laravel job instance. We also wanted freedom to modify the job payload. I will list what I did in steps:

• Set up a singleton service called RabbitMQ and created a service provider for it that initializes the connection.
• Created an artisan task that runs a subscription consumer loop. The loop looks something like:

  (get message)
  RabbitMQConsumeJob::dispatch(message)
  (repeat)

  This job will dispatch messages into a laravel queue that laravel horizon can process when it's running. So imagine I took the output of rabbitmq, plugged it into the input of the Laravel Queue. When we are running the laravel server, we also have another dyno running the rabbitmq consumer artisan job.

• To handle publishing, had to do something much simpler. Each time I wanted to publish a message, I would dispatch RabbitMQPublishJob::dispatch(exchange, queue, message...) and the job handler would use the RabbitMQService to actually publish the message. This way consuming and publishing are handled with queues.
• I wanted granular control of the whole process to match it to our internal business logic and doing it this way was a breeze. To test, I created a fake RabbitMQService that faked a connection and kept messages in an array of queues and asserted that things got pushed etc.