RPC
Articles on RPC between Node.js microservices: request/reply over a message queue, typed clients, RPC over Redis, and why internal APIs need not be REST.
7 articles
RPC over Redis in Node.js: patterns and pitfalls
How request/reply RPC over Redis actually works in Node.js — the correlation, timeout and delivery problems you have to solve yourself, why the old npm packages stalled, and how @imqueue turns it into typed, boilerplate-free calls.
read →RPC between Node.js microservices over a message queue
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.
read →Type-safe service-to-service communication in TypeScript
End-to-end types across service boundaries are easy inside one process and hard the moment you cross a network. Here's how to keep them without hand-writing clients or maintaining a schema language.
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 →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 →gRPC vs message-queue RPC for internal Node.js services
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's strengths for a lot less infrastructure.
read →