search

reactor / reactor-rabbitmq

Reactor RabbitMQ
Apache License 2.0
157 stars 55 forks source link

Do we really need queue semantics in the Sender? #107

Open gregturn opened 5 years ago

gregturn commented 5 years ago

I was confused when I saw Sender with methods like declareQueue(). I thought that in AMQP, queues were components of the Receiver, and that senders only talk to exchanges.

Seeing no declareQueue() methods on the Receiver, it almost sounds like the methods were put in the wrong class. This forced me to use Spring AMQP'sBindingBuilder` to construct the queue and bindings for the consumer.

acogoluegnes commented 5 years ago

Fair enough, the semantics behind the Sender are write operations, which loosely includes any operation on resources (exchanges, bindings, and queues). One benefit is to use only one class (and a fluent API) to configure a topology and publish messages.

This remark makes me think we could introduce (in 2.0) an Admin class to deal only with resources, just like in Spring AMQP. We could still be able to use a fluent API to configure and publish, but not on the same class.

acogoluegnes commented 5 years ago

Another comment leaning toward removing queue semantics from the Sender.