IMQ is an Intercommunication Messaging Queue Framework for service oriented back-end architectures
built with Node and TypeScript

Key Capabilities:

  • Massaging Queue as a base communication protocol between services (@imqueue/core)
  • RPC-like programming interface (@imqueue/rpc)
  • Rapid application development command line interface (@imqueue/cli)

It all enables developers to create back-end services (or microservices as a special case of SOA) very fast and focus only on functionality implementation without the need to take care of low-level implementation, following below key principles:


IMQ implements reliable communication between services. Depending on the exact needs, using safe delivery messaging and "leader" - "follower" deployment of messaging back-end engine provides possibility to fully guarantee data delivery between services.


IMQ supports several scaling possibilities on different levels:

Taking into account all above, there are no technical limits to handle any possible throughput in the designed system based on IMQ.


IMQ follows KISS (keep it short and simple) principles, making development using @imqueue easy and clear.


We tried to get the utmost from the technologies IMQ is based on. Benchmarking is a part of @imqueue/core, therefore it is possible to run and test it in your environment.

Here are some results we got on a single Intel Core i7 machine using 1 dedicated core for Redis process and 6 workers each assigned to it's own core by using 1Kb message sent asynchronously 10,000 times at a time:

Hence, in the worst case with all features turned on it is about tens of thousands messages round-trips per second for a single messaging backend engine which is fair enough to launch projects with a pretty high load.


IMQ respects smooth and clean development and delivery processes. By using command line tool it provides extensible way to organize service delivery based on your own needs. Currently it provides a default template which includes Git, Travis CI and Docker / DockerHub integration out-of-the-box.

Thus is a big plus that it allows to define custom boilerplate templates which will modify or provide completely another ways of delivery from your side.

How It Works

Explaining @imqueue internals

IMQ implements messaging queue over Redis, which works as a centralized message broker for communication between services and their clients.

Such schema provides several advantages:

Fom Development Point Of View

So, naturally each Service is a simple piece of software inside distributed system solving some specific task in it. That means that from development point of vew it is as simple as implementing class with exposed methods. As follows from that a Client is a local representation of a remote Service interface at this exact network point. All you need when it is required to call a certain Service method is to call a corresponding Client method, where Client will take care about delivering proper message to a queue and that massage will invoke corresponding Service method execution.

Yes, at development level it simply looks like remote procedures calls!

There is no need of manual implementation of the clients. All @imqueue services are self-describable and clients could be generated dynamically on-the-fly or to be pre-auto-generated files. That means that developer should be focused only on service implementation. Following the simple rules and best practices when developing a Service interface, writing the proper doc-blocks you'll get all-in-one:

Are you ready to try it?