Open anandkumarpatel opened 9 years ago
A publisher will ever only need to know if it is publishing an event or if it publishing a command. events will publish to a fanout commands will publish to a topic.
subscribers are harder to handle for an event the subscriber can either create a queue and attach it to the fanout, or it can create another exchange and then create a queue on that one. for commands, the subscriber will create a queue and attach to that specific topic.
since we are going to have to assert that queues and exchanges exist, I think we should set them up before we attempt to use pub/sub methods. This way we can fail early in a client application lifecycle if anything is wrong.
In order to do that we need general topology during connect time. we can pass them in a topology as options or we can create each programmatically Rabbit.bind('exchange').subscribe('host1')
we can start with the options way since it will be more clear what is happening
for the updated version of API lets think about some specific use cases, and create the best interface
events (pub/sub)
basic fanout
creating publisher
opts version
create options upfront during initialization of module
version 2
create events on the fly
creating consumer
opts version
create options upfront during initialization of module
version 2
create events on the fly
advance events
creating publisher
opts version
create options upfront during initialization of module
version 2
create events on the fly
creating consumer
opts version
pass in Exchange object to setup exchanges talking to exchanges
version 2
create events on the fly