Possible to support SQS? about nameko HOT 3 OPEN

Hi, apologies for the slow reply here.

SQS support is certainly feasible. The way the project has evolved means we've probably made some assumptions that AMQP will be used, but that's not by design and shouldn't remain the case.

Nameko is organised around the notion of "extensions" and the AMQP features are implemented as such. My feeling is that SQS support should be implemented as a parallel set of extensions (so an entrypoint and proxy pair for RPC/synchronous calls and a dispatcher and handler pair for pub-sub/asynchronous messages). Writing these as subclasses of the AMQP ones might allow some amount of code reuse but the existing extensions weren't built with this in mind, so it may not be easy, at least for the time being.

An alternative approach would be to let kombu handle the differences. It is intended to be an abstraction on top of multiple transports and SQS is supported. There are certainly a few places where nameko assumes it's talking to RabbitMQ though, so we'd need to track those down. But as I said above, I think the nicest way would be a new set extensions that reused as much as possible of the AMQP ones (or a base class extracted out of them).

The good news is that SQS support is something that I'm pretty sure I'm going to need soon, so there's likely to be some progress in this direction in the next month or so. I'll keep this issue updated. What are your requirements? RPC, pub-sub, both or something else?

from nameko.

Any word on this? :) Interested as well.

from nameko.

This is a great idea -- probably needs to be SQS + SNS, however.

SQS doesn't do pub-sub -- there is no exchange or routing concept.

The pub-sub pattern for AWS combines SNS topics and SQS queues.

from nameko.