An Inter-Communication Messaging Queue framework for SOA back-ends.
@imqueue is built with Node and TypeScript and works best when orchestrated by an API layer such as GraphQL. It lets developers create back-end services — or microservices as a special case of SOA — fast, focusing only on functionality while @imqueue handles the low-level messaging.
Reliable
Safe-delivery messaging plus "leader"/"follower" deployment of the back-end engine fully guarantee data delivery between services.
Scalable
Cluster the backend engine, fork across a machine's cores, and scale horizontally across servers — there is no technical limit to the throughput a system built on IMQ can handle.
Simple (KISS)
Low entry for JS/TypeScript developers — minutes to your first service. No "hidden knowledge", a clean JSON-based protocol, and familiar patterns (Messaging Queue and RPC).
Self-describing
Every service describes itself, so clients are generated dynamically on-the-fly or pre-generated to files. You focus only on the service.
A centralized broker
IMQ implements a messaging queue over a broker (Redis today, adapters are pluggable) that routes messages between services and their clients. All messages flow through a single point, so monitoring and debugging use the tooling the broker already gives you.
No service discovery to implement — instances compete for their messages. If one is busy or down, another consumes the message and delivers the response anyway. Load-balancing happens naturally, with good distribution across nodes.
Service & client model
From a development point of view a service is as simple as a class with exposed methods. A client is a local representation of that remote service's interface.
Call a client method and it takes care of delivering the message to the queue, invoking the matching service method, and returning the result. At development level it simply looks like remote procedure calls — and clients are generated for you, so you focus only on the service.
→ Get started in a few minutes