cody-greene / node-rabbitmq-client

RabbitMQ (0-9-1) client library with auto-reconnect & zero dependencies
MIT License
130 stars 9 forks source link

jackrabbit #56

Closed erSitzt closed 3 months ago

erSitzt commented 3 months ago

Hi,

i just noticed "pagerinc" in your profile.. i was wondering why there is another rabbitmq lib and what the reasoning behind this is ?

regards Dennis

cody-greene commented 3 months ago

Jackrabbit is a wrapper around amqplib . It was ~created~ forked from hunterloftis/jackrabbit by an employee of Pager, for internal use, before I joined the company. Don't use it. It's bad.

node-rabbitmq-client is a project that I started some time before joining Pager. I was irritated by the state of rabbitmq clients at the time (just look at all the attempts to wrap amqplib and add reconnection capability or better abstractions). I wanted something built from the ground up, with a more practical API.

erSitzt commented 3 months ago

Thank for the info ! I was checking almost every year if there is a better library for rabbitmq around.. jackrabbit worked quite well for simple rpc services for us.

I will try your lib, @pagerinc/jackrabbit was adding internal dependencies lately which i didnt like..

Did you try rascal ? i liked the config approach, for creating vhosts and stuff..

regards dennis

cody-greene commented 3 months ago

I have not used rascal. It appears to be yet another amqplib wrapper, and so shares the same fundamental issues with similar packages: many dependencies, awkward interfaces, and missing typescript definitions.

The config file feature is interesting because it addresses the problem of an expected broker topology. Something that barebones libs like amqplib, or python's pika, or even the offical Java client, don't consider at all. If an exchange does not exist, for example, then attempts to publish to that exchange will fail. Recovering from consumer/channel/connection errors goes hand-in-hand with assertions on the expected topology (queues, exchanges, and bindings between them).

For that reason the Consumer & Publisher interfaces in this (node-rabbitmq-client) allow you to declare your topology and will attempt to create these objects, if they do not exist, each time a publisher channel or conusmer is (re)established. This means you can manually delete a queue which has an active consumer, and the consumer will automatically recreate the queue and recover. Although it's not clear to me when rascal actually uses its config to create queues, exchanges & bindings, and if it could recover in the same situtations.