<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom">
  <title>@imqueue Blog</title>
  <subtitle>Articles about message-queue RPC for Node.js &amp; TypeScript microservices.</subtitle>
  <link href="https://imqueue.org/blog/feed.xml" rel="self"/>
  <link href="https://imqueue.org/blog/"/>
  <id>https://imqueue.org/blog/</id>
  <updated>2026-07-22T00:00:00Z</updated>
  <author><name>@imqueue</name><uri>https://imqueue.org/</uri></author><entry>
    <title>RPC between Node.js microservices over a message queue — no HTTP, no gRPC</title>
    <link href="https://imqueue.org/blog/rpc-over-message-queue-nodejs/"/>
    <id>https://imqueue.org/blog/rpc-over-message-queue-nodejs/</id>
    <published>2026-07-22T00:00:00Z</published>
    <updated>2026-07-22T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="rpc"/><category term="queue"/><category term="architecture"/><summary type="text">Why route internal service-to-service calls through a message queue instead of HTTP or gRPC — and how @imqueue makes those calls fully typed with zero client boilerplate.</summary>
  </entry><entry>
    <title>Type-safe service-to-service communication in TypeScript</title>
    <link href="https://imqueue.org/blog/type-safe-service-communication-typescript/"/>
    <id>https://imqueue.org/blog/type-safe-service-communication-typescript/</id>
    <published>2026-07-19T00:00:00Z</published>
    <updated>2026-07-19T00:00:00Z</updated><author><name>Serhiy Morenko</name><uri>https://imqueue.org/blog/authors/serhiy-morenko/</uri></author><category term="types"/><category term="rpc"/><category term="dx"/><summary type="text">End-to-end types across service boundaries are easy inside one process and hard the moment you cross a network. Here&#39;s how to keep them without hand-writing clients or maintaining a schema language.</summary>
  </entry><entry>
    <title>Stop hand-writing and maintaining your microservice clients</title>
    <link href="https://imqueue.org/blog/stop-hand-writing-microservice-clients/"/>
    <id>https://imqueue.org/blog/stop-hand-writing-microservice-clients/</id>
    <published>2026-07-17T00:00:00Z</published>
    <updated>2026-07-17T00:00:00Z</updated><author><name>Serhiy Morenko</name><uri>https://imqueue.org/blog/authors/serhiy-morenko/</uri></author><category term="clients"/><category term="types"/><category term="dx"/><summary type="text">Every service you call needs a client, and hand-maintained clients drift out of sync with the services they talk to. Here&#39;s why that happens and how to make the client fall out of the service for free.</summary>
  </entry><entry>
    <title>Load balancing internal microservices without a load balancer</title>
    <link href="https://imqueue.org/blog/load-balancing-microservices-without-a-load-balancer/"/>
    <id>https://imqueue.org/blog/load-balancing-microservices-without-a-load-balancer/</id>
    <published>2026-07-14T00:00:00Z</published>
    <updated>2026-07-14T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="load-balancing"/><category term="queue"/><category term="architecture"/><summary type="text">For internal service-to-service traffic, the load balancer you run and operate is often solving a problem a message queue solves for free. Here&#39;s the competing-consumers pattern and what it removes.</summary>
  </entry><entry>
    <title>Do your Node.js back-ends really need service discovery?</title>
    <link href="https://imqueue.org/blog/do-nodejs-backends-need-service-discovery/"/>
    <id>https://imqueue.org/blog/do-nodejs-backends-need-service-discovery/</id>
    <published>2026-07-12T00:00:00Z</published>
    <updated>2026-07-12T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="discovery"/><category term="architecture"/><category term="queue"/><summary type="text">Consul, etcd, DNS-SD — service discovery is a lot of machinery to stand up. Sometimes you genuinely need it; often you don&#39;t. Here&#39;s how to tell, and how a queue makes the question disappear.</summary>
  </entry><entry>
    <title>Back-pressure for Node.js services (and why HTTP makes it hard)</title>
    <link href="https://imqueue.org/blog/backpressure-nodejs-services/"/>
    <id>https://imqueue.org/blog/backpressure-nodejs-services/</id>
    <published>2026-07-09T00:00:00Z</published>
    <updated>2026-07-09T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="backpressure"/><category term="queue"/><category term="resilience"/><summary type="text">When a downstream service slows down, HTTP tends to turn that into a cascading failure. A queue absorbs the spike instead. Here&#39;s the difference, and the trade-offs to watch.</summary>
  </entry><entry>
    <title>Guaranteed message delivery: what it costs and when you need it</title>
    <link href="https://imqueue.org/blog/guaranteed-message-delivery-cost/"/>
    <id>https://imqueue.org/blog/guaranteed-message-delivery-cost/</id>
    <published>2026-07-07T00:00:00Z</published>
    <updated>2026-07-07T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="delivery"/><category term="queue"/><category term="resilience"/><summary type="text">&#34;Will I lose messages if a worker dies?&#34; is the right question — and the answer is a trade-off, not a yes/no. Here&#39;s how guaranteed delivery works, what it costs, and how to choose per workload.</summary>
  </entry><entry>
    <title>Cutting the boilerplate out of Node.js microservices</title>
    <link href="https://imqueue.org/blog/cutting-boilerplate-nodejs-microservices/"/>
    <id>https://imqueue.org/blog/cutting-boilerplate-nodejs-microservices/</id>
    <published>2026-07-04T00:00:00Z</published>
    <updated>2026-07-04T00:00:00Z</updated><author><name>Serhiy Morenko</name><uri>https://imqueue.org/blog/authors/serhiy-morenko/</uri></author><category term="dx"/><category term="tooling"/><category term="clients"/><summary type="text">Most of a new service&#39;s first commit is ceremony — transport wiring, serialization, a client, CI, a Dockerfile. Here&#39;s where the boilerplate hides and how to stop writing it by hand.</summary>
  </entry><entry>
    <title>Versioning microservices without breaking every caller</title>
    <link href="https://imqueue.org/blog/versioning-microservices-without-breaking-callers/"/>
    <id>https://imqueue.org/blog/versioning-microservices-without-breaking-callers/</id>
    <published>2026-07-02T00:00:00Z</published>
    <updated>2026-07-02T00:00:00Z</updated><author><name>Serhiy Morenko</name><uri>https://imqueue.org/blog/authors/serhiy-morenko/</uri></author><category term="versioning"/><category term="types"/><category term="dx"/><summary type="text">A change to one service&#39;s method quietly breaks the services that call it — and you find out in production. Here&#39;s how to make breaking changes loud at build time and coordinate releases across a fleet.</summary>
  </entry><entry>
    <title>Testing services that call each other — without booting the whole stack</title>
    <link href="https://imqueue.org/blog/testing-microservices-without-the-whole-stack/"/>
    <id>https://imqueue.org/blog/testing-microservices-without-the-whole-stack/</id>
    <published>2026-06-29T00:00:00Z</published>
    <updated>2026-06-29T00:00:00Z</updated><author><name>Serhiy Morenko</name><uri>https://imqueue.org/blog/authors/serhiy-morenko/</uri></author><category term="testing"/><category term="dx"/><category term="clients"/><summary type="text">Integration tests that require every service and its infrastructure running are slow, flaky, and painful. Here&#39;s a layered approach that tests most of your logic without spinning up the world.</summary>
  </entry><entry>
    <title>Internal APIs don&#39;t need to be REST</title>
    <link href="https://imqueue.org/blog/internal-apis-dont-need-rest/"/>
    <id>https://imqueue.org/blog/internal-apis-dont-need-rest/</id>
    <published>2026-06-27T00:00:00Z</published>
    <updated>2026-06-27T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="rpc"/><category term="architecture"/><category term="comparison"/><summary type="text">REST is a fine choice for public, resource-oriented APIs. For internal service-to-service calls it&#39;s often ceremony over a plain function call. Here&#39;s when to drop it and what to reach for instead.</summary>
  </entry><entry>
    <title>From monolith to services: a low-risk first extraction</title>
    <link href="https://imqueue.org/blog/monolith-to-services-first-extraction/"/>
    <id>https://imqueue.org/blog/monolith-to-services-first-extraction/</id>
    <published>2026-06-24T00:00:00Z</published>
    <updated>2026-06-24T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="architecture"/><category term="migration"/><category term="rpc"/><summary type="text">You don&#39;t migrate a monolith by rewriting it. You extract one capability, keep everything else in place, and repeat. Here&#39;s a concrete, low-risk first step for a Node.js team.</summary>
  </entry><entry>
    <title>Redis as a message bus: patterns beyond pub/sub</title>
    <link href="https://imqueue.org/blog/redis-message-bus-patterns/"/>
    <id>https://imqueue.org/blog/redis-message-bus-patterns/</id>
    <published>2026-06-22T00:00:00Z</published>
    <updated>2026-06-22T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="queue"/><category term="transport"/><category term="patterns"/><summary type="text">Most people know Redis pub/sub and stop there. Redis has richer primitives — lists, blocking pops, and streams — that make it a capable message bus. Here&#39;s a tour, and where each fits.</summary>
  </entry><entry>
    <title>@imqueue vs Moleculer: two takes on Node.js microservices</title>
    <link href="https://imqueue.org/blog/imqueue-vs-moleculer/"/>
    <id>https://imqueue.org/blog/imqueue-vs-moleculer/</id>
    <published>2026-06-19T00:00:00Z</published>
    <updated>2026-06-19T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="comparison"/><category term="frameworks"/><category term="architecture"/><summary type="text">Moleculer is a full-featured microservices framework with many transporters; @imqueue is a focused, TypeScript-first RPC layer over a message queue. Here&#39;s an honest comparison to help you pick.</summary>
  </entry><entry>
    <title>@imqueue vs NestJS microservices: framework vs transport</title>
    <link href="https://imqueue.org/blog/imqueue-vs-nestjs/"/>
    <id>https://imqueue.org/blog/imqueue-vs-nestjs/</id>
    <published>2026-06-17T00:00:00Z</published>
    <updated>2026-06-17T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="comparison"/><category term="frameworks"/><category term="architecture"/><summary type="text">NestJS is a full application framework with a microservices module; @imqueue is a focused RPC transport. They&#39;re not really competitors — here&#39;s how they differ and how they can work together.</summary>
  </entry><entry>
    <title>tRPC vs @imqueue: client–server types vs service–service RPC</title>
    <link href="https://imqueue.org/blog/imqueue-vs-trpc/"/>
    <id>https://imqueue.org/blog/imqueue-vs-trpc/</id>
    <published>2026-06-14T00:00:00Z</published>
    <updated>2026-06-14T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="comparison"/><category term="types"/><category term="rpc"/><summary type="text">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.</summary>
  </entry><entry>
    <title>@imqueue/job vs BullMQ: a simple Redis job queue vs a feature-rich one</title>
    <link href="https://imqueue.org/blog/imqueue-vs-bullmq/"/>
    <id>https://imqueue.org/blog/imqueue-vs-bullmq/</id>
    <published>2026-06-12T00:00:00Z</published>
    <updated>2026-06-12T00:00:00Z</updated><author><name>Andrii Glushko</name><uri>https://imqueue.org/blog/authors/andrii/</uri></author><category term="comparison"/><category term="queue"/><category term="jobs"/><summary type="text">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&#39;s an honest split — plus the thing @imqueue does that BullMQ doesn&#39;t.</summary>
  </entry><entry>
    <title>gRPC vs message-queue RPC for internal Node.js services</title>
    <link href="https://imqueue.org/blog/grpc-vs-message-queue-rpc/"/>
    <id>https://imqueue.org/blog/grpc-vs-message-queue-rpc/</id>
    <published>2026-06-09T00:00:00Z</published>
    <updated>2026-06-09T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="comparison"/><category term="rpc"/><category term="transport"/><summary type="text">gRPC is the default answer for typed RPC — and a great one, especially across languages. For an all-Node.js back-end, routing RPC through a queue trades some of gRPC&#39;s strengths for a lot less infrastructure.</summary>
  </entry><entry>
    <title>Benchmarking @imqueue: throughput, delivery modes, and how to measure your own</title>
    <link href="https://imqueue.org/blog/benchmarking-imqueue-throughput/"/>
    <id>https://imqueue.org/blog/benchmarking-imqueue-throughput/</id>
    <published>2026-06-07T00:00:00Z</published>
    <updated>2026-06-07T00:00:00Z</updated><author><name>Mykhailo Stadnyk</name><uri>https://imqueue.org/blog/authors/mykhailo-stadnyk/</uri></author><category term="performance"/><category term="queue"/><category term="benchmark"/><summary type="text">Real measured throughput for @imqueue&#39;s message queue — ~200k msg/sec unreliable, ~120k guaranteed on a 24-core box — what the delivery modes cost, and a reproducible harness to measure the figures that matter: yours.</summary>
  </entry>
</feed>
