Runnable / hermes

Runnable job queuing system interface abstraction for runnable's services
MIT License
3 stars 1 forks source link

new interface #27

Open anandkumarpatel opened 9 years ago

anandkumarpatel commented 9 years ago

for the updated version of API lets think about some specific use cases, and create the best interface

events (pub/sub)

basic fanout

one level fanout

creating publisher

opts version

create options upfront during initialization of module

opts = {
  publishedEvents: ['event1']
}
var client = Rabbit(opts);

client.publish('event1', data)

version 2

create events on the fly

Rabbit.publish('event1').fanoutExchange()

creating consumer

opts version

create options upfront during initialization of module

opts = {
  consumedEvents: ['event1']
}
var client = Rabbit(opts);

client.subscribe('event1', function())

version 2

create events on the fly

Rabbit.subscribe('event1', function)

advance events

advance fanout

creating publisher

opts version

create options upfront during initialization of module

opts = {
  publishedEvents: ['event1']
}
var client = Rabbit(opts);

client.publish('event1', data)

version 2

create events on the fly

Rabbit.publish('event1').fanoutExchange()

creating consumer

opts version

pass in Exchange object to setup exchanges talking to exchanges

opts = {
  consumedEvents: ['event1']
}
var client = Rabbit(opts);

client.setConsumer('event1', Exchange)
client.subscribe(Exchange, function)

version 2

create events on the fly

Rabbit.fanoutExchange('event1').topicExchange({opts}).subscribe('host1')
anandkumarpatel commented 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.

anandkumarpatel commented 9 years ago

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