Workq would be far better if it followed the AMQP (https://www.amqp.org/) or 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.
back
3 comments
At 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/ [1] https://cloud.google.com/pubsub/reference/rest/
I 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.
Just to clarify my own comment, I would want to see attributes like TTL made part of the queue, not part of the job.
Google 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.