Andrii Glushko
Software engineer and a maintainer of the @imqueue framework, contributing across its packages and developer tooling.
// POSTS BY ANDRII GLUSHKO
Nothing threw, and the job never ran: silent failures in a Node.js message queue
A send() that resolves with a message id nobody will ever deliver. A push() that returns cleanly onto a queue redis refused to write. Neither throws, and neither can — the caller has already moved on by the time redis answers. That silence is over: here is what each of those failures now writes to the log instead, and the one upgrade note that costs you a stack trace.
read →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 →@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 →Graceful shutdown and zero-drop deploys
Every deploy sends a kill signal to a process that is probably in the middle of something. Nothing 500s, no dashboard turns red, and the work is gone anyway. Here's what actually happens to an in-flight message on SIGTERM, and the built-in drain that keeps it.
read →One isolated imq CLI home per @imqueue project
Every imq invocation shares one ~/.imq — one config, one pid registry, one set of logs. Here's how to give each project its own isolated CLI environment with IMQ_CLI_HOME, plus recipes for direnv, shell wrappers, per-client tokens and disposable sandboxes.
read →Internal APIs don't need to be REST
REST is a fine choice for public, resource-oriented APIs. For internal service-to-service calls it's often ceremony over a plain function call. Here's when to drop it and what to reach for instead.
read →From monolith to services: a low-risk first extraction
You don't migrate a monolith by rewriting it. You extract one capability, keep everything else in place, and repeat. Here's a concrete, low-risk first step for a Node.js team.
read →@imqueue vs Moleculer: two takes on Node.js microservices
Moleculer is a full-featured microservices framework with many transporters; @imqueue is a focused, TypeScript-first RPC layer over a message queue. Here's an honest comparison to help you pick.
read →@imqueue vs NestJS microservices: framework vs transport
NestJS is a full application framework with a microservices module; @imqueue is a focused RPC transport. They're not really competitors — here's how they differ, where each is stronger, and how to run them together.
read →tRPC vs @imqueue: client–server types vs service–service RPC
tRPC gives you end-to-end types between a frontend and its backend. @imqueue gives you typed RPC between backend services over a queue. They solve adjacent — not competing — problems.
read →@imqueue/job vs BullMQ: Redis job queues compared
Both are Redis-backed job queues for Node.js. @imqueue/job is small, safe-by-default and scheduling-capable; BullMQ is the feature-rich one. Here's an honest split — plus the thing @imqueue does that BullMQ doesn't.
read →