DEV Community: Pedro Rogério

Node.js has plenty of circuit breakers. So why did I build another one?

Pedro Rogério — Mon, 27 Jul 2026 12:40:00 +0000

Every service I've worked on eventually grows the same scar tissue: a retry loop copy-pasted into six files, a circuit breaker bolted onto the payment client after an outage, a timeout wrapper someone wrote at 3 a.m. Each one slightly different. None of them talking to each other. And when things go wrong, nobody can answer the only question that matters during an incident: what is the resilience layer actually doing right now?

Java solved this years ago with resilience4j. .NET has Polly. Node.js... has pieces.

The gap

I evaluated what the ecosystem offers before writing a single line:

opossum is the best-known circuit breaker, mature and well maintained. But it's only a circuit breaker — retry is rudimentary, there's no bulkhead, no composition. Metrics need a plugin.

cockatiel is the closest thing to Polly: retry, breaker, timeout, bulkhead, composition. I genuinely like its design. But observability is where it stops — no native metrics, no pipeline-wide correlation — and maintenance has slowed.

The Sindre micro-libs (p-retry, p-timeout, p-limit) are excellent at exactly one thing each. But resilience is a system: a retry that doesn't know the circuit is open will happily sleep through backoff to hammer a dead dependency. Isolated pieces can't coordinate.

And there was one thing nobody documented properly, which became the reason I finally started typing:

Ordering is the whole game

Take four policies: retry, circuit breaker, timeout, fallback. The same four, nested in two different orders, produce two very different systems:

retry( circuitBreaker( timeout( fn ) ) )   // A
circuitBreaker( retry( timeout( fn ) ) )   // B

In A, every attempt flows through the breaker, so the breaker sees the dependency's true failure rate — and when the circuit opens mid-retry, the retry finds out immediately.

In B, the breaker sees one outcome per retry cycle: three real failures against the dependency count as a single failure. The circuit opens far later than the dependency's actual state justifies, and the retry keeps sleeping through backoff against a broker that's clearly down.

Most libraries let you build either one without ever telling you there's a difference. That's not an API problem — it's a documentation-of-consequences problem. I wanted a library where composition and its consequences are the headline feature, not an afterthought.

So I built breakwater.

What it looks like

npm install breakwater

import { resilience, exponential } from 'breakwater'

const payments = resilience({
  retry: { attempts: 3, backoff: exponential({ initial: 200 }) },
  rateLimit: { limit: 100, interval: 60_000 },
  bulkhead: { concurrency: 20, queue: 50 },
  circuitBreaker: { name: 'payments-api', failureThreshold: 0.5 },
  timeout: 2_000,
  fallback: () => ({ status: 'pending', queued: true })
})

const charge = await payments.execute(({ signal }) => api.post('/charge', body, { signal }))

resilience() is the batteries-included path with a fixed, documented order:

fallback( retry( rateLimit( bulkhead( circuitBreaker( timeout( fn ) ) ) ) ) )

Each position is deliberate. The local guards (rate limit, bulkhead) sit outside the breaker, because your own saturation must never open a circuit that describes the dependency's health. The timeout sits innermost so every attempt gets its own budget — and a hung call becomes a countable failure instead of an invisible one.

Need a different order? compose() reads exactly like the nested calls:

import { compose, retry, circuitBreaker, timeout } from 'breakwater'

const policy = compose(
  retry({ attempts: 3 }),          // outermost
  circuitBreaker({ name: 'api' }),
  timeout(2_000)                   // innermost
)

And because the result of compose() is itself a policy, compositions compose again. The ordering guide walks through the classic configurations with sequence diagrams — it's the page I wish every resilience library had.

Details that only show up in production

A few behaviors took far more design effort than any diagram suggests, because they only matter when things are already going wrong:

Policies coordinate through errors. Every error carries a stable code and a retryable flag. CircuitOpenError declares itself retryable: false — so the default retry gives up instantly instead of backing off against an open circuit. Rate-limit and bulkhead rejections stay retryable, because saturation is transient. This is why the pieces compose correctly out of the box.

Cancellation is not failure. One AbortSignal — combining your external cancellation, timeouts, everything — reaches your function. And when the caller aborts, nothing counts it as a failure: retry doesn't retry it, the breaker doesn't tally it, fallback doesn't replace it. Your user closing a tab should never open a circuit.

Timeouts don't lie. A genuine domain error that lands after the deadline propagates as itself, never masked as a TimeoutError. A call the caller cancelled is cancellation, not a timeout. Your error dashboards reflect what actually happened.

Monitoring never changes an outcome. An event listener or metrics collector that throws is isolated and reported — a bug in your telemetry cannot turn a successful payment into an error.

Observability without plugins

Every policy emits typed events, one correlationId crosses the whole pipeline, and stateful policies expose stats():

breaker.stats()
// { state: 'open', failureRate: 0.85, lastError, openedAt, nextAttemptAt, ... }

CircuitOpenError carries that snapshot too — a proper Retry-After header is three lines. For metrics pipelines, implement one MetricsCollector interface and it wires everywhere; define your policies once in a named registry and every metric comes out labeled:

import { policies } from 'breakwater'

policies.define('payments-api', { retry: { attempts: 3 }, circuitBreaker: {}, timeout: 2_000 })

// anywhere else — same name, same instance, genuinely shared circuit state
await policies.get('payments-api').execute(({ signal }) => api.post('/charge', body, { signal }))

A health endpoint over every policy in your app is a policies.names().map(...) away.

Dogfooding, honestly

I maintain a RabbitMQ client library that had its own hand-rolled circuit breaker and retry loop — the exact scar tissue this post opened with. Migrating it to breakwater deleted the bespoke resilience code, upgraded the publisher to the correct retry-outside-the-breaker ordering, and every one of its existing tests passed unchanged, including destructive reconnection tests against a real broker. That migration shipped; it's running in production today.

It also taught me things no unit test would: that consumers of a hand-rolled retry expect the raw last error (there's a documented unwrap pattern now), and that sync call sites need a recreate-the-policy idiom for breaker resets. Both learnings went straight into the docs.

What it is — and isn't (yet)

breakwater today: retry (backoff strategies + jitter + total deadline), timeout (cooperative and aggressive), circuit breaker (sliding windows, bounded half-open probing, manual isolation), bulkhead, rate limiting (token bucket and exact sliding window), chained fallbacks, composition, typed events, metrics, named policies. Zero runtime dependencies, TypeScript-native, dual ESM/CJS, Node >= 22.

Planned and designed for (the circuit breaker's state store is already pluggable): distributed circuit breaker state over Redis — ten instances of your service agreeing that an endpoint is down, with a single instance elected to probe recovery. Plus ready-made Prometheus/OpenTelemetry collectors and a stale-while-open response cache.

The API is heading to 1.0; until then, minor versions may adjust it.

Try it

GitHub: github.com/pinceladasdaweb/breakwater
npm: npmjs.com/package/breakwater
Start here: the composition & ordering guide

If you've ever debugged a retry storm at 3 a.m., I'd genuinely love your feedback — issues and PRs welcome. And if breakwater saves you from writing one more bespoke circuit breaker, it did its job.

My Redis library said the write succeeded. Redis was down.

Pedro Rogério — Fri, 24 Jul 2026 12:59:40 +0000

Last year I audited my RabbitMQ library and discovered it couldn't survive a single reconnect. I turned the whole ordeal into a playbook, and I promised myself I'd run it against the next library in my drawer.

The next library was a Redis client I wrote two years ago. The README advertised connection pooling, pub/sub, distributed locking, "battle-tested error handling" and "production-ready resilience".

Here's what the audit found: there was no pooling. There was no pub/sub. There was no locking. There were no tests. And the resilience — the one thing a Redis wrapper exists for — was worse than absent. It was actively lying.

This is the story of the second time I learned the same lesson, plus the parts that were new.

The write that succeeded by doing nothing

Every command in the library went through a health check. If Redis was unhealthy, this happened:

if (!isHealthy) {
  this.logger.warn(`Redis is not healthy. Skipping ${command} operation.`)
  return null
}

Read that again. set, incr, lpush — writes — would resolve successfully having done nothing. No throw, no rejection. Your checkout flow calls set, gets a resolved promise, tells the user their cart is saved. The cart does not exist.

The best part? The README documented this as a feature: "Methods return null when Redis is not healthy." I had documented data loss and called it graceful degradation.

And for reads it's worse in a subtler way: get returning null means "key doesn't exist" — or now, "Redis was down". Your cache layer can't tell a miss from an outage.

The fix is a contract, not a patch:

throw new RedisClientError(
  `Redis is not connected. Cannot execute '${command}'.`,
  command,
  'REDIS_UNAVAILABLE'
)

Structured errors with a code. The caller branches on err.code === 'REDIS_UNAVAILABLE', never on message text. A write that can't happen must be loud. This was a breaking change — and it's exactly why I fixed it before the library had public users. Defaults are free to change until the day someone depends on them.

The reconnection layer that fought the driver — and lost to itself

My library sits on top of ioredis. ioredis already reconnects. It has retryStrategy, exponential backoff, an offline queue, resubscription. It is good at this.

Two-years-ago me didn't trust it, so he built a second reconnection layer on top. Every error or close event scheduled a manual reconnect:

scheduleReconnect () {
  this.reconnectAttempts++
  setTimeout(() => this.attemptConnection(), this.reconnectInterval)
}

async attemptConnection () {
  this.client = this.redisConfig.createRedisClient()  // ← a NEW client
  // ...
}

Spot it? Every attempt created a brand-new ioredis client without destroying the previous one. The old client — with its own retryStrategy — kept reconnecting forever in the background. Every drop leaked one more client, each running its own infinite retry loop against your server. A one-minute Redis outage turned my "resilience layer" into a connection storm.

It gets better. After the first attempt, the validation ping was skipped entirely:

if (!this.initialConnectionAttempted) {
  await this.client.ping()
  this.initialConnectionAttempted = true
}
// every reconnection after this point:
this.isConnected = true   // sure, why not

Every reconnection "succeeded" unconditionally. isConnected = true while Redis was on fire. The reconnection had never worked and never been tested — the exact disease from the RabbitMQ library, in a different body.

And my favorite: disconnect() called quit(), which made ioredis emit close… and the close handler scheduled a reconnect. Graceful shutdown resurrected the connection. The library refused to die. There's something poetic about a resilience layer whose only reliably working feature is refusing to let you leave.

The fix was not code. It was deletion. The entire manual layer went away — the driver is the single owner of reconnection, and my library only tracks state and emits events. Four critical bugs died in one commit that removed more lines than it added.

The test that earns the word "resilient"

From the RabbitMQ refactor I kept one ritual: no reliability claim without a test that kills the connection for real, from the server side. For Redis, that's CLIENT KILL:

await client.set('sacred:before', 'ok')          // works
await killAllClientsFromTheServer()               // CLIENT KILL, server-side
await waitFor(async () =>
  await client.set('sacred:after', 'ok') === 'OK' // works again, same client
)

Plus the two regression probes that document the old bugs forever: after recovery, the server must see exactly the same number of connections as before (no leaked reconnection loops), and after disconnect() the client must stay disconnected (no resurrection).

First run against the old code: the resurrection probe failed exactly as predicted, and the test runner never exited — leaked timers kept the process alive. The suite needed Ctrl-C. When your test suite can't die, your library can't either.

After the surgery: everything green, the runner exits by itself, and recovery after a server-side kill went from ~2 seconds to ~110 milliseconds — because reacting to the driver's events beats waiting for your own arbitrary timer.

A parade of small lies

The deep read found plenty more. A sample:

The scan that read other people's keys. getAllStream() used ioredis' scanStream — which does not apply your keyPrefix to the MATCH pattern. With a prefix configured, scanning for user:* matched zero of your own keys. And scanning * swept the entire database, including other applications' keys, which then got your prefix wrongly added on the follow-up GET and came back as null. The old code had mysterious logging for these "null values", fetching TTL and type for each one. That wasn't observability. That was a bug filing reports about itself.

maxRetryAttempts: 0 meant infinity. The classic options.x || default — zero is falsy, so "never retry" became "retry forever". Same for block: 0 in stream reads, which in Redis means "block forever" and was silently dropped. ?? exists. Use it.

XGROUP DESTROY couldn't work. The wrapper appended a default stream id to every subcommand, so the destroy documented in my own README sent a stray $ and died with a protocol error. The README showed example code that had never once executed successfully.

Every command paid a toll. The health check ran a real PING — serialized before your command, up to once per five seconds. Fail-fast checks must be local and free (client.status === 'ready'); the driver already owns the expensive part.

None of these are exotic. They're what the first test you ever write catches. There were no tests.

Then I had to earn the README

Deleting fiction from the README was easy. But two of the fictional features were genuinely good ideas — so this time they got built for real, with the reliability ritual applied from day one.

Pub/sub lives on a dedicated connection (a subscribed Redis connection can't run normal commands — the library manages that for you), and its sacred test kills the subscriber server-side and proves messages flow again after recovery.

Distributed locking is SET NX PX with a random token, and release/extend go through Lua scripts that check the token — a holder whose lock expired can never delete the new holder's lock. The README says, in bold, that this is a single-instance mutex and not Redlock. Honesty is a feature.

And they compose. The cache helper uses the lock internally for stampede protection:

const report = await redis.getOrSetJson('report:daily', 3600, buildReport, { lock: true })

Ten concurrent cache misses, one producer call — the test proves exactly that, with real concurrency against a real Redis.

The reviews that found what I couldn't

"Looking finished" is still the most dangerous state, so finished code got adversarial reviews — every finding had to be reproduced live before I accepted it. Two highlights that survived the process:

A producer returning undefined in the cache helper poisoned the key: JSON.stringify(undefined) is undefined, which got stored as an empty string with a TTL — and every later read exploded with SyntaxError until it expired. One absent-minded return and the key is bricked for an hour.

And the packaging check — install the actual tarball in a clean project — caught two defects no unit test could: my prepare script made npm v12 nag every consumer with an allow-scripts approval warning, and TypeScript consumers in CommonJS hit TS1479 because a "type": "module" package needs dual declaration files (index.d.ts + index.d.cts). Validate the artifact, not the repo.

What shipped

50 tests: 24 unit, 26 integration against a real Redis — including server-side CLIENT KILL recovery for both commands and pub/sub
1 runtime dependency (ioredis). The old version had three: pino and pino-pretty shipped a dev log formatter to every production install. Bring your own logger; the fallback is 25 dependency-free lines
Fail-fast structured errors, observable lifecycle events, working optimistic locking via dedicated connections
CI on Node 22/24 with a real Redis service container, npm trusted publishing (OIDC) with provenance, zero lifecycle scripts in the package

It's on npm as @pinceladasdaweb/redis, source at github.com/pinceladasdaweb/redis.

The lessons, second edition

Docs are a spec you've already published. Either the code honors them or the docs change. My README described a different, better library — and the gap was invisible because nothing tested the claims.
Read everything before fixing anything. The four worst bugs looked independent and were one defect: a reconnection layer that shouldn't exist. Patch-by-patch would have polished each symptom and kept the disease.
Don't own what your driver owns. The best resilience code I wrote this month was a deletion. If you're wrapping a client that already reconnects, your job is what happens around reconnection — state, events, dedicated connections — not a competing loop.
A write that resolves while doing nothing is data loss with good manners. Fail fast, fail loud, fail with a code.
Kill it from the server side. CLIENT KILL is one command. If your library claims resilience and your test suite has never dropped a connection for real, you don't have a resilience feature — you have a resilience rumor.

Same ending as last time, because it's still true: this library now survives everything I could think of throwing at it, and it has zero production mileage under other people's workloads. If you run Redis with Node and feel like breaking something, I'd genuinely love the bug reports.

Turns out "looking finished" is still the bug. At least this time I knew where to look.

My RabbitMQ library looked production-ready. It couldn't survive a single reconnect.

Pedro Rogério — Sun, 19 Jul 2026 17:13:46 +0000

For a couple of years I had a RabbitMQ client library sitting in a private repo. On paper it was impressive: automatic reconnection, channel pooling, a circuit breaker, four rate-limiting strategies, gzip compression, dead letter queues, worker-thread consumers, delayed messages. Over 1,200 lines in the main class alone.

I never quite trusted it enough to publish. Recently I decided to find out whether that instinct was right.

It was. The single most important feature of a message-broker client — surviving a connection drop — had never worked. Not "worked poorly". Never worked. And nothing in the repo could have told me, because there wasn't a single test.

This is the story of the audit, the rebuild, and the release of @pinceladasdaweb/rabbitmq. It's also a collection of lessons I wish I'd internalized years earlier, because none of these bugs were exotic. They were all sitting in plain sight, waiting for a failure path to be exercised for the first time in production.

The audit: what "looks done" actually hides

The library had the shape of a finished product. Rich API, detailed README, twenty example scripts. Here's a sample of what a deep read of the code actually found.

The reconnection that reconnected to nothing. The connection layer dutifully detected drops, retried with exponential backoff, and re-established the TCP connection. Then... nothing. The channel pool — the thing every publish and consume goes through — was only ever created inside connect(), and the reconnection path never called it. After any network blip, every operation would throw Not connected forever, while the connection state proudly reported connected. The recovery code existed; it recreated consumers using channels captured in closures from before the drop — channels that were dead. It had clearly never been executed.

The rate limiter that crashed on its own feature. The block-a-key feature stored blocked keys in a Set... and called this.blocked.set(key, Date.now()) on it. Set has no .set(). Calling blockKey() threw a TypeError, every time, since the day it was written.

The circuit breaker state that didn't exist. The public API exposed getCircuitBreakerState(), which called this.#circuitBreaker.getState() — a method the circuit breaker class simply did not have.

The dead-letter helper with the wrong signature. moveToDeadLetter() called the publish method with four arguments in the wrong order, so the name of the queue was published as the message body, to the wrong exchange.

The library that killed your process. The constructor registered SIGINT, SIGTERM, uncaughtException and unhandledRejection handlers — and called process.exit() in them. A library. Any unhandled rejection anywhere in your application would cause my dependency to shut your process down.

None of these are subtle bugs. They're the kind of thing the first test you ever write catches. Which brings me to the first lesson.

Lesson 1: features are cheap; invariants are expensive. An API surface can look complete while every failure path is fiction. The happy path is maybe 20% of an infrastructure library — the rest is what happens during the bad minutes, and that's exactly the part that "it runs on my machine" never exercises.

If you claim resilience, your CI has to actually break things

The rebuild started with the reliability core: reconnection has to restore the channel pool, re-assert topology, and recreate every consumer on fresh channels. But I'd been burned by "code that looks like it recovers", so the real work was making the claim falsifiable.

The integration suite now runs against a real RabbitMQ (Docker locally, a service container in GitHub Actions) and includes this test — the one I care most about in the entire repo:

test('recovers channel pool and consumers after a forced connection drop', async () => {
  const reconnected = new Promise(resolve => rabbitMQ.once('reconnected', resolve))

  // Ask the broker to close every AMQP connection, simulating a real outage.
  await forceCloseAllConnections() // DELETE /api/connections/* via the management API

  await reconnected

  const countBefore = received.length
  await rabbitMQ.publish(ROUTING_KEY, { after: 'reconnect' })

  await waitFor(() => received.length > countBefore)
  assert.equal(rabbitMQ.getClusterStatus().connectionState, 'connected')
})

No mocks. The broker genuinely kills the connection; the library genuinely has to come back: pool rebuilt, exchange re-asserted, consumer re-subscribed on a new channel, message flowing again. This runs on every pull request.

Using the management HTTP API for the kill switch (instead of docker restart) was a small trick that paid off: it works identically on a laptop and inside a CI service container, and it's fast.

Lesson 2: a resilience feature without a test that injects the failure is a rumor. The test that kills your broker connection is worth more than the thousand lines of recovery code it validates.

The adversarial review: 42 candidates, 10 confirmed bugs

With the core rebuilt and a test harness in place, I ran a structured review of the source: multiple independent passes over the code, each hunting from a different angle — line-by-line, lifecycle invariants, cross-module contracts, plus efficiency and design-depth sweeps. Every candidate finding then got adversarially verified against the code before I accepted it.

Ten confirmed bugs came out. Three of my favorites, because each one represents a category:

1. The option that silently discarded messages.

async retryOperation (operation, maxRetries = 3, delay = 1000) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    // ...
  }
}

Spot it? Pass { maxRetries: 0 } — a perfectly reasonable "try once, don't retry" intent — and the loop body never runs. The operation is never attempted, channel.publish is never called, and the promise resolves successfully. The circuit breaker even records a success. Silent message loss, triggered by a documented option. The fix is one line (Math.max(1, maxRetries)), plus a regression test that pins the semantics forever.

2. The poison message that ate a consumer. A message with a corrupt gzip body would fail to decode, get nacked with requeue: true, be redelivered instantly, fail again... forever. With prefetch: 1, one bad message parked an entire queue while burning 100% CPU. Undecodable messages now go to the dead letter queue — failure handling should drain problems, not recirculate them.

3. The unroutable dead-letter that vanished. Moving a message to a DLQ published it without the mandatory flag. If the dead-letter routing had no binding — one topology mistake away — the broker would confirm the publish and silently drop the message. The method resolved, logged success, and the message ceased to exist. It now publishes with mandatory: true, listens for basic.return, and rejects loudly when the DLQ isn't routable.

There were seven more: a disconnect()/connect() cycle that permanently disabled auto-reconnection, consumer callback failures tripping the circuit breaker that gates publishing, a fire-and-forget publish that could hang forever awaiting 'drain' on a dead channel, duplicate consumers spawned by racing recovery paths...

Lesson 3: bugs cluster in the seams. Almost every confirmed finding lived at an intersection — between two recovery mechanisms, between an option's edge value and a default, between "the callback succeeded" and "the ack was delivered". Reviews that only read functions in isolation don't find these. You have to trace the interactions.

Your test suite also protects you from everyone else

Two things happened during this project that had nothing to do with my code, and the test suite caught both.

The dependency major-bump. Mid-rebuild, I upgraded amqplib from 0.10 to 2.0 — a jump across two majors of the library this whole thing wraps. The entire integration suite (confirms, compression round-trips, forced reconnections, delayed messages) passed against the new version in one afternoon. Without the suite, that upgrade would have been an act of faith deferred indefinitely.

The floating Docker tag. My CI used rabbitmq:4-management-alpine. One day that tag started resolving to RabbitMQ 4.3, which rejected the delayed-message plugin version I bundled (built for 4.0.x). CI went red before any user ever saw the problem. The fix taught me to pin brokers and plugins as a matched pair (rabbitmq:4.2-management-alpine + plugin 4.2.0) — a floating major tag in CI is a time bomb with a pleasant default.

Lesson 4: automated tests are not just about your bugs. They're your early-warning system for upstream majors, ecosystem drift, and infrastructure that changes underneath you.

Dependencies are promises

At the start, the library shipped four runtime dependencies, including pino and pino-pretty — a pretty-printer for development logs, in every production install.

It now ships two: amqplib and a small cache. The logger question is the interesting one. The library used to create its own pino instance at import time — its own format, its own destination, disconnected from whatever the host application does. But an infrastructure library shouldn't own a logging pipeline; it should write to whatever you give it:

import pino from 'pino'

const rabbit = new RabbitMQ({
  endpoints: ['localhost:5672'],
  logger: pino({ name: 'rabbitmq' }) // any pino/winston/bunyan instance works
})

If you inject nothing, a 25-line dependency-free console logger provides timestamped, leveled output. Nobody pays for a logging stack they already have.

The same thinking applied to process lifecycle: the library no longer touches your signal handlers. Graceful shutdown is one explicit call — rabbit.enableGracefulShutdown() — and it's opt-in, because your process belongs to you, not to your dependencies.

A small release-engineering war story

The publish pipeline (GitHub Actions → npm on every merge to main) had its own baptism by fire. Two merges landed on main in quick succession; two release runs raced each other. The first published 1.0.1 to npm, then failed pushing the git tag back (the branch had moved). The second run recomputed "next version = 1.0.1" from the now-stale package.json — and npm refused to publish over an existing version. Deadlock: every subsequent release run would fail the same way.

Two structural fixes, both worth stealing:

The registry is the source of truth. The workflow now asks npm what the latest published version is (npm view <pkg> version) and bumps from that, never from package.json. Whatever half-finished state a previous run left behind, the next run self-corrects.
Serialize your releases. A concurrency: { group: publish } block means rapid merges queue instead of racing.

Lesson 5: release automation fails in the middle, not at the edges. Design every step to be safe to re-run, and derive state from systems of record, not from files a previous failed run may or may not have updated.

Where it landed

The library is now public: @pinceladasdaweb/rabbitmq.

npm install @pinceladasdaweb/rabbitmq

import RabbitMQ from '@pinceladasdaweb/rabbitmq'

const rabbit = new RabbitMQ({
  endpoints: ['localhost:5672'],
  exchange: { name: 'orders', type: 'direct' }
})

await rabbit.connect()

await rabbit.subscribe('order-processing', async (content, message) => {
  await handleOrder(content) // auto-ack on success, nack → DLQ on throw
})

await rabbit.publish('order.created', { id: 42 }) // publisher-confirmed

rabbit.on('reconnected', () => console.log('survived an outage, consumers restored'))

What's in the box: automatic reconnection with full state recovery (pool, topology, consumers), publisher confirms on everything, per-key rate limiting (token bucket, leaky bucket, fixed and sliding windows), a circuit breaker that's isolated from consumer failures, transparent gzip compression, first-class dead-letter support (createQueue, moveToDeadLetter, processDeadLetterQueue), delayed messages via the official plugin, worker-thread parallel consumers with automatic respawn, dependency-ordered sequential processing, consumer lifecycle management (unsubscribe, consumerCancelled/consumerRecovered/consumerLost events), and TypeScript declarations checked in strict mode on CI.

Guarding all of it: 87 automated tests — 72 unit, 15 integration against a real broker including the forced-outage scenario — running on Node 22 and 24 on every pull request, plus 22 runnable examples that double as living documentation.

And in the spirit of the whole post, the honest part: this library has excellent test coverage and zero production mileage under other people's workloads. Those are different kinds of confidence, and only one of them can be built alone. If you run RabbitMQ in Node and any of this resonates, I'd genuinely love an issue, a hard question, or a war story from your queue topology: github.com/pinceladasdaweb/rabbitmq.

The library I was too embarrassed to publish taught me more in this rebuild than it did in all the years it sat in a folder looking finished. Turns out "looking finished" was the bug.

Node URL Shortener

Pedro Rogério — Fri, 11 Jun 2021 19:49:08 +0000

I recently ended up creating a URL shortener using NodeJS, Fastify, Postgres and Redis for study purposes. If you think it might be useful for you, if only for study purposes too, come take a look:

https://github.com/pinceladasdaweb/node-url-shortener

Developing a RESTful API using Fastify

Pedro Rogério — Mon, 08 Feb 2021 10:58:57 +0000

You who are tired of seeing examples of REST API in Node using Express will be very interested in this boilerplate that I ended up developing using Traefik, Docker, Docker Compose, Fastify, JWT and Mongodb.

https://github.com/pinceladasdaweb/docker-fastify-restful-api

Happy coding!