4 ms·
Workq would be far better if it followed the AMQP (https://www.amqp.org/ https://www.amqp.org/) or SQS (https://aws.amazon.com/sqs/ https://aws.amazon.com/sqs/)
by AdamN 10y ago
Workq would be far better if it followed the AMQP (https://www.amqp.org/ https://www.amqp.org/) or SQS (https://aws.amazon.com/sqs/ https://aws.amazon.com/sqs/) specs and terminology. There's already a large body of work on those two protocols. SQS is much simpler than AMQP so it's a good first-step.
- AdamN 10y agoJust to clarify my own comment, I would want to see attributes like TTL made part of the queue, not part of the job.
- gtaylor 10y agoGoogle PubSub has TTLs on each message, with the queue having the default value for new messages. I've found this to work really well in practice.
- sluukkonen 10y agoI have no experience with SQS, but there is definitely space for a simpler queue implementation (or even a standard) than AMQP. I think it's needlessly complex for many problem domains.
- billhathaway 10y agoAt a high level, SQS is simple, but there are a lot of additions AWS has made over time such as dead letter queues, message attributes, delayed messages. Some of these settings are per-queue level, some are overridable on a per-message basis. Not that AMQP isn't super complex, but SQS has a larger feature set surface area than a lot of people realize. There is also a bit of oddness experienced when people try to use the various AWS libraries to hit non-AWS hosted endpoints since the happy path for these is to connect to AWS regions. I worked on an internal SQS clone in the past (not related to current employer). From a queue API perspective, I like iron.io's MQ API [0] and Google Cloud PubSub[1]. Disclaimer: I currently work for Nest, an Alphabet company [0] http://dev.iron.io/mq/3/ http://dev.iron.io/mq/3/ [1] https://cloud.google.com/pubsub/reference/rest/ https://cloud.google.com/pubsub/reference/rest/