Server side modules with Architect

After my last notes on a client side modular architecture using require.js I'll talk about server side modules using Architect.

Modules

In my opinion every application (not only the bigger ones) needs to be divided into interdependent modules. This helps a lot when you deal with testing and enhancing your application.

In node.js applications, you will see and use this pattern very often:

//import a module
var Database = require('./db');

// initialize a module using some options 
var db = new Database('http://my.db.connection');

// initializing a module injecting a dependency 
var usermanager = require('./usermanager')(db);

But what if you want to use this module in other applications ? In this case you should make an npm independent package for each module, of course. And, in the main application you would initialize each package in the proper order. This is repeatitive and tedious furthermore, when the number of the packages starts to get bigger, initializing each module in the proper order can be an issue.

From modules to plugins

Architect uses a simple declarative syntax to explain the interconnections between packages. It also starts the system in the correct order initializing each package just once.
I recommend to read the documentation on github. It's very clear and detailed.

Express.js and Architect

I have set up a simple express.js/architect boilerplate to show how to use Architect to make an extensible express.js application.


I hope this will be useful ...

P.S.
A friend of mine suggest me to use a git subtree for each package. Nice idea!

Occamsrazor.js 2.0 API ehnancement

I released version 2.0 of occamsrazor.js. My goal is to further simplify the API. This example is taken from my last post:

//mediator

var pubsub = occamsrazor();

// from now a validator is a simple function
var is_archive = function (obj){
    return 'getNumbers' in obj;
};

// the archive object

var archive = (function (){
    var numbers = [];
    return {
        getNumbers: function (){
            return numbers;
        },
        addItem: function (number){
            numbers.push(number);
            // this notify the event to the mediator
            pubsub.publish('changed', this);
        }
    };
}());

// the printsum isn't changed

var printsum = (function (){
    return {
        print: function (n){
            console.log(n);
        },
        sum_and_print: function (archive){
            var i,sum = 0;
            for(i = 0;i < archive.length; i++){
                sum += archive[i];
            }
            this.print(sum);
        }
    };
}());

// subscribe the event
// subscribe is an alias of "add" and "on"

// the list of validators now is before the function
pubsub.subscribe(["changed",is_archive], function (evt, archive){
    printsum.sum_and_print(archive.getNumbers());
});

//you can use a single string instead of a function as a validator

Mediator pattern with occamsrazor.js

The mediator design pattern can be very useful to decouple a group of objects. Let's see how.

Let's say we have two very simple objects. The first is an archive of numbers:

var archive = (function (){
    var numbers = [];
    return {
        getNumbers: function (){
            return archive;
        },
        addItem: function (number){
            archive.push(number);
        }
    };
}());

The second object prints the sum of the numbers of the previous object:

var printsum = (function (){
    return {
        print: function (n){
            console.log(n);
        },
        sum_and_print: function (archive){
            var i,sum = 0;
            for(i = 0;i < archive.length; i++){
                sum += archive[i];
            }
            this.print(n)
        }
    };
}());

Ok. Now we need to recalculate and print the sum each time a new item is added to the archive. The first solution is straightforward:

...

        addItem: function (number){
            archive.push(number);
            // we call directly the function
            printsum.sum_and_print(archive);
        }
...

This could be a solution but It has a drawback: we bind explicity the two objects together. With many objects and direct dependencies this could be very difficult to manage. Moreover, chaging or adding other dependencies could translate in changing extensively the (already tested) code.

The mediator

The mediator is an object that mediates between other objects. Instead of calling functions directly we notify events to the mediator. The mediator calls every function that is subscribed to a certain event.

Let's rewrite the example using occamsrazor.js to build a mediator:

//mediator

var pubsub = occamsrazor();

// we need 2 validators, one for the event and the second for the object

// this validate the type of the event

var is_changed_event = occamsrazor.validator(function (evt){
    return evt === 'changed';
});


// this validate the type of the object

var is_archive = occamsrazor.validator(function (obj){
    return 'getNumbers' in obj;
});


// the archive object

var archive = (function (){
    var numbers = [];
    return {
        getNumbers: function (){
            return numbers;
        },
        addItem: function (number){
            numbers.push(number);
            // this notify the event to the mediator
            pubsub.publish('changed', this);
        }
    };
}());

// the printsum isn't changed

var printsum = (function (){
    return {
        print: function (n){
            console.log(n);
        },
        sum_and_print: function (archive){
            var i,sum = 0;
            for(i = 0;i < archive.length; i++){
                sum += archive[i];
            }
            this.print(sum);
        }
    };
}());

// subscribe the event

pubsub.subscribe(function (evt, archive){
    printsum.sum_and_print(archive.getNumbers());
}, [is_changed_event,is_archive])

Build a mediator with occamsrazor.js has another advantage: events are notified only for the objects that pass every validator.

Next challenge: try to integrate occamsrazor.js with backbone.js 
Stay tuned !

Occamsrazor.js: A Javascript component registry

Occam's Razor
This principle is often summarized as "other things being equal, a simpler explanation is better than a more complex one."

http://en.wikipedia.org/wiki/Occam%27s_razor

I am a Plone developer. For those who do not know, Plone is a powerful CMS based on the Zope application server (written in Python).

One of the best features of this CMS is the Zope Component Architecture (ZCA). It borns as a part of the Zope 3 project but It's a quite independent set of modules. ZCA allows you to build component based application.

I really missed a Javascript implementation of the ZCA or something similar. But I haven't found anything !!! Maybe, building complex and pluggable CMS in Javascript is not yet so common (no, I'm not surprised).

ZCA in Javascript ?

So I started to think to port the ZCA in Javascript, unfortunately It's not easily portable (It's written in Python and rely on Python inheritance implementation).
Furthermore some aspects of the ZCA perplexed me. These are the dark spots of the ZCA (all in my own opinion):

• Interfaces

Interfaces are an unusual concept for dynamic languages like Python and Javascript. For example the concept of "interface" (design-by-contract programming) doesn't fit perfectly in an environment where you can create, delete or modify any attribute of an object at run time.
Python and Javascript coding style privilege attribute checking over type checking. For this reason in the day-to-day work the main use of Zope interfaces is often to "mark" an object without enforcing a specific interface (intended as a subset of attributes/methods).

• Interface inheritance

Inheritance is a tricky matter.
Zope interface implementation is tightly coupled with the Python inheritance implementation. While it's powerful, it is also quite complex to figure out in complex inheritance chains.
Furthermore it's quite difficult to port the library in a different environment (for example Javascript).

• Unnecessary functions and component types

ZCA API could be simpler furthermore it uses an unusual and rich terminology (components, adapters, utilities etc.).

occamsrazor.js

I eventually decided to work around some ideas and try to improve and simplify the ZCA.
The result is Occamsrazor.js

Occamsrazor.js is a library useful to decouple a functionality from the code that provide it.

Documentation and source code is here.

I'm very curious to have some feedback ...