Why is Exchange configuration driven by Consumers instead of Publishers about go-rabbitmq HOT 13 CLOSED

I'm totally open to that idea. Feel free to open a PR or I'll get to it when I can

from go-rabbitmq.

I've started working on a PR in my local fork, if anyone is interested.

https://github.com/NicklasWallgren/go-rabbitmq/pull/1/files

from go-rabbitmq.

@wagslane what's your thoughts on also allowing publishers to create the exchange, not only the consumer?

The current behaviour caught me as a surprise. Having gone through the streadway/amqp examples, my brain was wired into the idea that both parties could create the exchange. Combined with the idea of go-rabbitmq handling the low-levels for us, I for some reason struggled badly understanding why on earth the exchange was not created when the publisher interacting with RabbitMQ.

Honestly didn't even think it might have helped to start a consumer at that point, we didn't have that service ready yet, but wanted to rollout the publishing part out first and verify the RabbitMQ mechanics were created as expected.

Steering away from a philosophical discussion about right or wrong, if we had the opportunity to choose if the exchange could be created by the publisher too, that would have been really helpful for our workflow & desire for independent rollouts.

from go-rabbitmq.

Everyone concerned with this thread please read the new docs on the main branch. This issue should be resolved. Please let me know as soon as you can if this new API will work.

from go-rabbitmq.

It's a good question, and I'm open to changing my mind, that said let me present my reasoning.

Primarily, this library is a "batteries included" library, the goal is sane defaults and such. It makes sense to me that you should be able to start a consumer and have it "just work", even if the exchange you're attaching to doesn't yet exist. If it doesn't your consumer will create it for you. That said, the default options WILL NOT create an exchange for you, you have to ask for that explicitly.

Additionally, this library will error out and alert you if you try to create an exchange that already exists and it doesn't have the parameters you expect:

ExchangeDeclare declares an exchange on the server. If the exchange does not already exist, the server will create it. If the exchange exists, the server verifies that it is of the provided type, durability and auto-delete flags.

from go-rabbitmq.

It's a good question, and I'm open to changing my mind, that said let me present my reasoning.

Primarily, this library is a "batteries included" library, the goal is sane defaults and such. It makes sense to me that you should be able to start a consumer and have it "just work", even if the exchange you're attaching to doesn't yet exist. If it doesn't your consumer will create it for you. That said, the default options WILL NOT create an exchange for you, you have to ask for that explicitly.

Additionally, this library will error out and alert you if you try to create an exchange that already exists and it doesn't have the parameters you expect:

ExchangeDeclare declares an exchange on the server. If the exchange does not already exist, the server will create it. If the exchange exists, the server verifies that it is of the provided type, durability and auto-delete flags.

understood, thanks for the explanation! logical and reasonable

i ended up forking the repository in order to have publisher-driven exchange creation and consumer-driven queue creation

from go-rabbitmq.

It would be really helpful if the publisher could create the exchange as well.

from go-rabbitmq.

Great, I might have a go at it later this week.

from go-rabbitmq.

@h44z @wagslane If the design is finalized, Can I help?

Having configuration driven by either Publisher or Consumer would be good to have. Otherwise, One has to write the consumer first before publishing anything to the rabbitmq.

from go-rabbitmq.

@aaqaishtyaq Have a look at #91

from go-rabbitmq.

@NicklasWallgren Thanks for the PR. Can we please look into merging it?

from go-rabbitmq.

When considering merging this pr, our service environment consumers will restart the service, which will cause our publishers to be unable to publish messages

from go-rabbitmq.

Resolved in 0.11.0

from go-rabbitmq.