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?