search

graze / queue

:postbox: Flexible abstraction for working with queues in PHP.
MIT License
49 stars 10 forks source link

Implement more adapters #8

Open sjparkinson opened 9 years ago

sjparkinson commented 9 years ago

Here's a list of adapters I'd love to see this project support:

joemeehan commented 9 years ago

RabbitMQ?

sjparkinson commented 9 years ago

RabbitMQ?

It uses the AMQP standard :smile:.

pentium10 commented 8 years ago

BeanstalkD

sjparkinson commented 8 years ago

BeanstalkD

@pentium10 thanks for the suggestion! If you're up for implementing the adapter yourself let us know, otherwise we'll make time for it in the near future.

stevenscg commented 8 years ago

This list looks pretty solid so far. I would +1 AMQP and add Redis and PDO.

We use AMQP via php-ampqlib right now, but we are also planning to transition to SQS and beyond once we find an appropriate abstraction class.

Redis is a good parity play vs other queue abstraction projects.

PDO (MySQL mainly) is also good for parity, but still supports distribution of producers and consumers and a low bar for folks that don't want to setup other systems yet.

Are you still developing and supporting the project? Using it for real workloads?

sjparkinson commented 8 years ago

Hi @stevenscg, we are still supporting the project, it's getting a lot of use internally so I can't see that changing either.

(Woops, pressed Shift + Enter too soon...)

Thanks for the amqp :+1:, I want to make some time soon to work on more adapters, but let me know if your interested in taking that one on.

PDO is a new one for me, didn't realised it supported the idea of producers and consumers, will take a look tomorrow!

stevenscg commented 8 years ago

@sjparkinson Good to hear. I'll dig in a bit more and possibly work up some examples and write up separate issues if I have questions. An AMQP adapter may certainly be an option.

Re PDO: Even though we aren't supposed to use databases as queues, I've seen quite a few implementations in my search for a good abstraction. The Laravel Queue and several others, for example, work from Jobs and Failed_jobs tables. Producers write "job" rows into the table and the consumers then have to reserve, work or fail the job, and then delete the rows.

I've deduced that Laravel queuing model is designed mostly for deferring/delaying work within a monolithic app so it probably is not a perfect analog for what you have here. This is driven by the concept that a single "job" class is used to both create the job and handle it. Nice until you want to pass a job into a completely different system (or something other than PHP) that does not have access to the original job class.