(Mostly replying to addisonj) I wrote a similar module, leveraging amqp: https://github.com/mateodelnorte/servicebus
Take a looksy. Matt On Friday, March 8, 2013 6:38:11 PM UTC-5, addisonj wrote: > > Slightly late to the party, but I just wrote this wrapper around node-amqp > that provides some higher level APIs for resourced based distribution of > messages. > > I know this partially is about not having to use another process, but as > far as messaging goes, rabbitmq is pretty impressive piece of software, and > I don't think you can beat it when you need resiliency. (mirrored queues > are pretty impressive things) > > https://github.com/addisonj/node-distributor > > It uses topic exchanges to do either a work-queue messaging model or pub > sub through exclusive exchanges. It has some unique such as the definition > json document which describes all the resources and topics a service > offers. The client just needs this definition file to begin consuming. > > Its really purpose built for us here at i.TV (github.com/idottv) but > maybe some of you can get use out of it as well. The docs are a bit weak, > ping me if you have any questions. > > > > > > > > > On Fri, Mar 8, 2013 at 11:46 AM, tjholowaychuk > <[email protected]<javascript:> > > wrote: > >> It depends on your application of course, but an event bus is brittle >> by-design, >> that's why I was mentioning that a more structured/domain-specific >> approach with >> zeromq or similar would be an easier sell as far as scaling goes, it's >> easy to pop >> in new nodes for a specific task vs trying to scale out a behemoth >> event bus. >> >> On Mar 8, 2:18 am, Micheil Smith <[email protected]> wrote: >> > @TJ Redis is great, until a point, which is: do you need redundancy; >> Making >> > pub/sub scale and >> > be resilient to failures is quite a tricky problem. For instance, >> LinkedIn >> > uses Apache Kafka. >> > >> > An anecdote: I know a company that used redis for the backbone of their >> > services APIs and network, it worked great, until that one day when >> redis >> > crashed; granted, that had never happened before then, but when redis >> did >> > crash, it meant that all services started buffering in memory, then >> those >> > services died, redis restarted, got utterly overloaded again, and died >> > again, then more services died. It basically took an entire network >> reset >> > to fix it. >> > >> > Sure, there were hot-slaves, but in a pub/sub type environment, those >> don't >> > really help you that much. >> > >> > I think there's other better solutions, and I totally disagree with the >> > "just use redis" approach. >> > >> > – Micheil >> > >> > >> > >> > >> > >> > >> > >> > On Thursday, March 7, 2013 4:29:46 AM UTC, tjholowaychuk wrote: >> > >> > > IMO event buses are usually not a great solution, but if that's all >> you >> > > need I would just use redis pubsub, >> > > otherwise a more structured approach with axon/zmq works well >> > >> > > On Wednesday, 6 March 2013 12:35:38 UTC-8, Tim Dickinson wrote: >> > >> > >> I'm looking for a pure node event bus. Something like hook.io but >> that >> > >> is kept up to date. >> > >> > >> I have been thinking of building my own module using >> > >>https://github.com/visionmedia/axonbut if something is already out >> > >> there then why not use it. >> > >> > >> What I'm doing is have a few processes that are Independence of each >> > >> other. There can be a master process or peer2peer type setup. Each >> process >> > >> and listen/subscribe to events as other process emit/publish events. >> I like >> > >> the ruby nats system but I'm looking for something that is written >> in node. >> > >> I know there is a client for node for nats but i don't want to have >> to run >> > >> a ruby process if i don't have to. >> > >> > >> I really like hook.io but it uses a lot of memory and is kind slow. >> if I >> > >> have more then a few processes hook.io gets really slow. >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
