Introduction

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:

Reliability

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.

Scalability

IMQ supports several scaling possibilities on different levels:

Clustering backend engine (Redis)
Fork-based scaling on single machine to utilize all its cores
Network based horizontal scaling, running as many service copies as needed across multiple servers

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

Simplicity

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

Low-level entry for JS/Typescript developers - only couple of minutes are needed to implement the first basic service
No need in very specific "hidden knowledge" to develop services with @imqueue
Clean and easy to understand JSON-based messaging protocol
Based on well-known, easy to understand patterns, like Messaging Queue and RPC (remote procedure calls)
Simple configuration. Being flexible though providing sufficient amount of configuration options @imqueue satisfies different needs

Performance

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:

For unsafe delivery communication it is fluctuated between 40,000 - 50,000 round-trips of messages per second
For safe delivery communication it is around 20,000 - 25,000 round-trips of messages per second
With the use of compression it is around 20,000 - 25,000 round-trips of messages per second
Safe delivery with compression turned on is about 16,000 - 18,000 round-trips of messages per second

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.

Delivery

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:

Simplicity (take a look at it!)
No need to implement any kind of service discovery, as it is auto-discoverable scheme - service instances compete for their messages, so as far as instance is busy or down message is consumed by another instance and delivers the response to a proper client any way. It means there is no need to check if exact copy of the service instance is dead or alive.
No need to implement any additional load-balancing. Service instances compete for messages and do load-balancing naturally with a good distribution between nodes.
All messages are flowing through a single system point and can be easily monitored, which simplifies debugging and monitoring as far as Redis provides complete set of tools doing that.

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:

Implementation at one place
Auto-generated client code whenever it is needed
Auto-generated service-related documentation
IDE service-related code auto-completions

Are you ready to try it?