Open albertvp opened 10 years ago
You are moving int the right direction. I agree we should have different queues and pub subs that the exchange uses.
if we focus on the Queues and Pubsubs, we could potentially have people have combinations.
var queue = require('bus.io-queue-koa')();
var pubsub = require('bus.io-queue-redis')();
var bus = require('bus.io')()
bus.queue(queue);
bus.pubsub(pubsub);
@albertvp @paulforbes42 What do you think?
To scale the platform we must have a queue, but if we want to use it on any simple app like the demos I think we should have this options to build a simple bus:
Obviously, the current solution is more robust.
I agree. The Queue
and PubSub
objects are to be wrappers for the real queue and pub subs. So if we implements a package called bus.io-queue-koa
it KoaQueue
class would be an instanceof Queue
while encapsulating the Koa
application.
Sorry, I don't know what you mean about the KoaQueue
.
I think I miss a middle layer between lib/server.js
and this module plus bus.io-messages
, delivering the messages anyway if it cannot be queued or stored, yes if the resources are active... I mean, that way we could manage different kind of actors defining a taxonomy:
Sorry, bus.io-queue-koa
is an example of a possible package we may make to use the Koa
queue. The proposed package bus.io-queue-koa
is a binding that bus.io-exchange
uses.
bus.io-messages
simply listens to a socket.io socket connection and calls emit('message', message)
each time it receives an event
from the socket.io socket connection. lib/server.js
listens for these message
events from bus.io-messages
and then pushes them through the incoming()
receiver. The other end of incoming()
receiver is a link to bus.io-exchange
instance. When the bus.io-exchange
instance gets the message it publishes the message to the bus.io-exchange
Queue()
instance. The Queue
class simply encapsulates and provides a simple interface to a queue. I just so happened decided to use redis
for the queue at the time.
Thanks, I understand that and how is on top of socket.io and redis. Is a very good choice, I'm figuring out what can really do a bus in all senses with minimum requirements in any environment. :ok_hand:
Checkout Koa
it is inspired from ZeroMQ
wow, To use Koa you must be running node 0.11.9 or higher?
This will be running without redis and will have a server with an API without socket.io?
So you want to use co
libs? What about mqtt
?
I still want to use socket up they are complete separated
On Thursday, June 12, 2014, Albert Vilà Picas notifications@github.com wrote:
wow, To use Koa you must be running node 0.11.9 or higher?
This will be running without redis and will have a server with an API without socket.io? So you want to use co libs? What about mqtt?
— Reply to this email directly or view it on GitHub https://github.com/turbonetix/bus.io-exchange/issues/1#issuecomment-45868109 .
Koa
was just an example
Follow the pull request I am working on. I am making lots of changes to bus.io-exchange. Cleaning up, simplifying it, and tying bus.io-common to it.
Hi Nathan, I have tested the demo and examples of bus.io and I'm finding out how redis manages the pubsub queue, it's great!
However, I think that if redis connection is not established then should use the in-memory process (just like socket.io) for event subscription, do you think it's possible?
Maybe the strategy pattern for this requirement (redis not available) is the best way:
... as seen on passportjs https://www.npmjs.org/search?q=passport