MicroMono: microservices you can run inside one process

The claim is switching, not scaling

MicroMono is a framework for developing micro-services in monolithic style or reversed, and the key word in that sentence is switch. It lets you switch and mix between micro-service and monolithic styles without changing the code. The framing in the README is that before, these were two things which always connected with VS, meaning Visual Studio, and now you have the ability to get the best of both worlds. The introduction gives the reasoning at more length. A monolithic structure is easy to understand and develop because that is how people think when designing, but it becomes a different story when it has more and more features or you want to deploy it to serve hundreds of thousands of users, and then there is the micro-services architecture. The README is careful to note that micro-services are a double-edged sword and not a free lunch, and that sometimes you have to rewrite the entire application to meet the requirements of the new architecture, and even then it may not be as elegant or efficient as desired because complexity and costs spiral out of control. The goal stated at the end is to let you choose the trade-offs for different circumstances.

Three parts: web framework, RPC and front end assets

MicroMono involves three parts of application development. The web framework covers http routing, middleware and page rendering. Remote procedure calls are the second part. And the third is front-end code management, which is the static asset files of JavaScript and CSS. The README notes that this should sound familiar, because MicroMono is built with proven open source frameworks and libraries, naming express and JSPM, and that you will find yourself at home if you have used either before. The point of listing the parts is that they are all solved by something you already know, and the contribution MicroMono makes is how they connect to each other and how a service is defined so that the same code can be mounted locally or reached over the network. Inside that there are two kinds of component. A balancer serves requests directly from clients and proxies requests to the right services behind it. A service runs the code which provides the actual feature.

A service is a package, not a process

The definition of a service is the part of the design that makes the switching work. A service is a standalone package which groups related features together as a unit. It could have only one RPC endpoint, or it may have http routing code and client side dependencies, and the README asks you to think of it as a micro-monolithic application with everything you need to run that part of the business logic. In the current Node.js implementation it is also an npm package, so in the package.json file you can define npm dependencies as well as the required libraries for client-side code. The important consequence is that the word service here is a packaging concept, not a process concept. A service can be required into the same process, and the same service can be started as its own process and reached over the network, and the calling code does not have to know which of the two is happening. That is what makes mixing the two styles possible rather than merely switchable.

Defining a service with the express route table

The example in the README shows a service defined as a subclass of a base class, and the routing is the interesting part:

// Require micromono and get the Service base class
var Service = require('micromono').Service;

// Subclass Service class to define your service
// (Backbone/Ampersand style inheritance)
var SimpleHttpService = Service.extend({
  // `route` is the object where you define all your routing handlers
  route: {
    'get::/hello/:name': function(req, res) {
      // Basically, this handler function will be directly attached to
      // internal express instance created by micromono. So, any express
      // route handler could be ported to micromono without any modification.
      var name = req.params.name;
      res.send('Hello, ' + name);
    }
  }
});

The route key format of method and path is what a familiar express handler looks like, and the comment makes the portability claim explicit, that any express route handler could be ported without modification because the handler is attached directly to an internal express instance created by micromono. The inheritance style is named too, described as Backbone or Ampersand style. So the learning curve for someone coming from express is close to zero, and the value of the framework is not the routing but the fact that the same route table works whether the service is in-process or across the network.

The balancer, the channel and the announcement spec

The balancer is the piece that makes a distributed deployment work, and the README gives both a command line route and a route for an existing application. The design section is where the real design work is, and it is the service announcement specification, which is listed as the last item in the documentation table of contents. The service concept depends on services finding each other, and that discovery is the announcement. The dependency list gives a hint about the mechanism, since it includes `socketmq` and `engine.io` along with `msgpack-lite`, which together suggest a message queue over websocket transport with a compact binary encoding for the messages, and `jdad` for what is presumably a JSON or document helper. The topics on the repository list channel, framework, microservice, node and rpc. The channel concept, listed in the documentation as its own section, is the transport that carries the announcements and the RPC traffic, and it is the piece that would have to work across languages and platforms for the design to be portable as the README claims.

The dependency list tells you the era

The package.json is dated in an obvious way, and reading it is useful if you are considering the design rather than the code. The runtime dependencies are pinned to exact versions rather than ranges, with express 4.15.3, http-proxy 1.16.2, jspm 0.16.53, engine.io 3.1.0, socketmq 0.10.1, superpipe 0.14.0, msgpack-lite 0.1.26, cmdenv 0.5.0, jdad 0.2.0, callsite 1.0.0, debug 2.6.8, ip 1.1.5 and a set of lodash micro-modules. JSPM for the front end assets, http-proxy for the balancer's proxying, express for the routing, socketmq and engine.io for the channel, and superpipe for the streaming pipe abstraction. The lodash micro-modules rather than the lodash package is a small detail that dates it precisely. The repository itself is structured as a book, with a `book.json` and a `SUMMARY.md`, a `doc/` directory and a `bin/` directory, and the release scripts use `mversion` to bump the patch, minor or major version and push the tags, which is a release process you would not use today.

The examples are a worked example of the pattern

There are several demos in the example folder, and the README describes three of them. The account service utilizes passport.js and exposes its authentication features as a service. The home service uses the features provided by the account service to protect a private page. And the io service illustrates how to use socket.io, over websocket, in your application. The account and home pair is the interesting one, because it is the smallest complete demonstration of the whole idea: one service provides authentication, another consumes it, and the two are wired together through the framework rather than by a direct require. The example directory also contains a `balancer/` directory, a `channel/` directory, an `rpc-adapters/` directory, a `Dockerfile`, a `docker-compose.yml`, a `Makefile` and a `test/` directory, so the examples cover the deployment and test story as well as the code. The only requirement to run them is Node.js.

Where this is the wrong choice

The limits are stated by the project and by the dates. The most direct statement is the italicised note in the README, that the current implementation of micromono is purely in node.js and is still in its early stages, that it uses open standards and has a clearly defined service specification so porting to other languages and platforms is possible and encouraged, and that the project needs help to make it better. That is an author asking for contributors, which tells you the state of the thing. The versions tell you the rest. The newest release tags are 0.1.35 from 2015-12-01, 0.1.34 and 0.1.33 from 2015-11-26, while the package metadata in the repository declares version 0.10.1, so the tree has moved well past the last published tag without a release. Combined with exact-pinned dependencies from 2016 and a Travis CI badge, this is a project that stopped. The second limit is the design premise itself. The whole framework assumes a service boundary can be added to an existing monolith without rewriting it, and while that is a valuable idea, the price is a layer of indirection between your code and the request, and the README's own admission that the trade-offs are to be chosen per circumstance is a hint that the framework does not make that choice for you. The third is the RPC story, which the documentation treats as one of three pillars and which you would be building your own cross-language contract on, in a project with no releases to depend on.

Editorial conclusion

MicroMono is worth studying if the question you are asking is how a codebase can move between a monolith and separately deployed services without rewriting it, because the service announcement specification and the balancer are a concrete answer to that question. It is not a framework to adopt today, since the newest release tag is from 2015 and the README itself says the implementation is purely in Node.js and still in its early stages. Before you copy any of its ideas, read the design section on the service announcement specification, and treat the code as a reference implementation rather than a dependency. The last push was on 2026-07-26, the package metadata declares version 0.10.1, and the licence is MIT.

Frequently asked questions

Official sources

1. License: MIT
2. lsm/micromono on GitHub
3. Project website
4. README
5. Releases