Steelmesh is a Node.js development / deployment platform that is designed to work in conjuction with systems like CouchDB (i.e. distributed document stores).
Steelmesh has primarily been designed for hosting “behind the firewall” node applications in, dare I say it, enterprise environments. It really hasn’t been designed for your next gazillion user startup or other such webscale deployments.
What Steelmesh does do a bang up job on though, is making working with horizontally scaled, homogeneous clusters, really easy. Heck it’s almost fun.
Steelmesh is designed to be different to other Node.js hosting options.
While other Node hosting solutions are primarily geared towards hosting a single (and hopefully popular) node application, Steelmesh aims to make hosting multiple applications on the same system (physical or virtualized) a more manageable task.
Current techniques and processes for building Node.js applications focus on creating a webserver, binding to particular routes, and then binding that webserver instance to a particular port on the machine.
Shown below, for instance, is a trivial example that uses the excellent Express.js framework:
var app = express.createServer();
app.get('/', function(req, res){
res.send('Hello World');
});
app.listen(3000);
If you are hosting your application on your own server, then you might be selecting port 80 as the port to bind to, or potentially hosting your node application behind nginx and proxying traffic through to your application.
While these solutions are ok, older and much more boring systems have provided application multi-tenancy for quite some time, and allow you to deploy apps A,B & C into a single server instance.
In actual fact, Express also provides this functionality by allowing express server instances to be mounted within other server instances. Steelmesh uses these application mountpoints to allow you to run multiple applications within the one instance.
When application updates are intercepted, at the moment Steelmesh performs a restart to ensure that applications are correctly loaded. This is done gracefully by downloading the new application files, spawning new workers using the new application files, and once the new workers are available, instructing the old workers to shutdown.
Steelmesh is made up of three primary components:
The server is the primary component of Steelmesh, and is responsible for initiating the other supporting processes. Additionally, Steelmesh is written using the cluster module of Node, and thus forks a worker process to serve incoming HTTP requests on port 6633 (by default).
The Monitor process is responsible for distributing both application and data updates in the Steelmesh 1.0 platform. This process is handled thanks to ChangeMachine which responds to change notifications from CouchDB and takes appropriate action.
Core application updates are captured through listing for _changes against the steelmesh db configured on Couch. When an application update is detected, the monitor simply sends a message to the steelmesh core to restart the Steelmesh App Server. As application updates are processed on startup of Steelmesh, and workers are restarted gracefully this works well to ensure traffic is served while keeping applications up-to-date.
In addition to application updates, applications that specify CouchDB data connections are also monitored for changes, and when an update is detected these are passed through to the registered change handler within the application.
It should be noted, however, that this functionality will not be implemented in Steelmesh 2.0 as this will be considered the responsibility of an individual application to monitor updates.
The Steelmesh Dashboard was developed as a part of Steelmesh 1.0 to assist organisations that aren’t able to interact with CouchDB directly. At this stage, the Dashboard is very much a beta component of Steelmesh.