Blog
News, releases and articles about @imqueue. Page 3 of 8.
The N+1 problem when GraphQL resolvers call microservices
A field resolver runs once per parent object. Put a service call inside it and one innocent-looking query becomes twenty-six. Here is the same query measured at 26 calls and at 3, why your latency chart will not show you the difference, and the two ways the fix comes back silently empty.
read →Distributed tracing for Node.js services over a message queue
The standard objection to queue-based RPC is that you lose the trace: the caller sends, something else picks it up, and the connection between them is gone. It isn't — the trace context rides in the request metadata. Here is a measured three-process trace, and the four ways it silently comes out wrong.
read →@imqueue vs NATS: a framework and a transport are not the same choice
NATS is a messaging system; @imqueue is an RPC framework that happens to use one. Comparing them means deciding how much of the contract you want to write yourself — and whether your fleet is Node-only.
read →How Node.js services talk to each other in 2026: the honest options
REST, gRPC, tRPC, NATS, a framework like NestJS or Moleculer, or RPC over a message queue. Six real approaches, what each one costs, and the two questions that actually decide it — including when @imqueue is the wrong answer.
read →One notification, every replica: the LISTEN/NOTIFY duplicate problem
LISTEN/NOTIFY is a broadcast, not a queue. Scale a Node app to three replicas and the same notification gets handled three times — no error, no warning, three charges on the card. Here's why, and what an inter-process lock actually does about it.
read →