Echo JS 0.11.0

<~>
tracker1 29 days ago. link 2 points ▲ ▼
Given other existing clients, I'm curious as to the "why" on creating/using this one vs. some of the others.  I am a bit familiar with shortcomings I've experienced from other clients.

Also, a nice to have addition would be an implementation of request/response channels (ie: distributed rpc).  Of course on the latter part, I've mostly moved to using Redis for coordinating that type of work... despite SPOF issues.

Replies

pinceladasdaweb 21 days ago. link 1 point ▲ ▼
Fair question! Two honest answers:

It started as scratching my own itch — each existing option left me wanting something: amqplib is deliberately low-level (no recovery at all), amqp-connection-manager reconnects the socket but stops at the connection
layer (consumer/channel/topology recovery is still your problem) and hasn't seen much maintenance lately. Rascal is solid but more config-driven than I wanted.

What I tried to do differently was make the reliability claims falsifiable: the CI suite force-kills every connection through the management API on each PR and asserts full recovery — channel pool rebuilt, topology re-asserted,
consumers resubscribed on fresh channels, messages flowing again. Plus some batteries that usually end up as app code: per-key rate limiting, a circuit breaker isolated from consumer failures, poison messages draining to DLQs instead of hot-looping, worker-thread consumers. Two runtime deps,
bring-your-own-logger, no process signal hijacking.

The honest trade-off: other clients have years of production mileage; this one has a test suite and ten days on npm. If you're up for sharing the shortcomings you've hit with other clients, those war stories are exactly what I want shaping the roadmap.

Request/response is a great call. RabbitMQ's direct reply-to
(amq.rabbitmq.reply-to) makes it nearly free given confirms, correlation ids and dedicated channels are already in place — I've opened an issue with a design spec here: https://github.com/pinceladasdaweb/rabbitmq/issues/11 (feedback very welcome). And yeah, Redis for that coordination is fair...

right up until the SPOF bites at 3am. :)