Scaffold Like Us

We need the audience of this article to have a certain degree of exposures to Node.js or Javascript coding.

If you are a business decision maker who is from PHP background, you are already know how difficult it is to control the proliferation of index.php scripts without the proper use of scaffolding aids like DRUPAL, LARAVEL or even WordPress. But theses tools are weighing several tons already! Let's enter the nimble and potent world of nodejs.

As of this writing, there are a multitude of open-source node-based scaffolding recommendations, such as:

They are very well-documented, superbly-crafted, battle-tested scaffolding strategies, which generally follow the MVC design pattern. Individually, any one of the strategies will work well for you under a relatively small scope, even if you have more than one projects. Here is a hypothetical resulting folder stuctures for your web server utilzing the above scaffolding codes:

   /var/www

     my-ecommerce-project
        server.js
        routes/
        model/*
        views/*
        public/*

     her-marketing-project
        server.js
        routes/
        model/*
        views/*
        public/*

     his-cms-project
        server.js
        routes/
        model/*
        views/*
        public/*

The above strategy of giving total freedom to each project may work or may result in an unsustainable mess of repeated violations of DO NOT REPEAT YOURSELF. How can we avoid this potential second scenario?

Let's do a slight transformation from the above by a central thinker/administrator. It will look like a physical scaffold for hotel or high-rise buildings:

    /var/www
      company-initiative-1-folder

         server.js (ONE OF THE TWO PROGRAMS CONTROLLED BY THE CENTRAL COORDINATOR)

         routes/
            index.js (TWO OF THE TWO PROGRAMS CONTROLLED BY THE CENTRAL COORDINATOR)
            one/*
            two/*
            thr/*
            six/*

         model/
            one/*
            two/*
            thr/*
            six/*

         views/
            one/*
            two/*
            thr/*
            six/*

         public/
            one/*
            two/*
            thr/*
            six/*

Then we will invite four sample tenant projects (corporatewide_menu, ecommerce, marketing, cms):

   /var/www
     company-initiative-1-folder    company-initiative-1-folder

        server.js (ONE OF THE TWO PROGRAMS CONTROLLED BY THE CENTRAL COORDINATOR)  

        routes/
          index.js (TWO OF THE TWO PROGRAMS CONTROLLED BY THE CENTRAL COORDINATOR)
          one_corporatewide_menu/index.js
          two_ecommerce/index.js
          thr_marketing/index.js
          six_cms/index.js

        model/
          one_corporatewide_menu/*
          two_ecommerce/*
          thr_marketing/*
          six_cms/*

        views/
          one_corporatewide_menu/*
          two_ecommerce/*
          thr_marketing/*
          six_cms/*

        public/
          one_corporatewide_menu/*
          two_ecommerce/*
          thr_marketing/*
          six_cms/*

   /var/www
     company-initiative-2-folder

What are the benefits and disadvantages here? There will be a sudden transparency within the company's project inventory. Finally we will have the development budgets under control. The company controls the scaffolding words or floor IDs like ("one", "two", "thr", "six", etc), and project teams control the project IDs or tenant IDs (like "ecommerce", "marketing", "cms", etc).

For the project teams, there is almost no loss of project freedom, just to gain additional non-intrusive services from the central coordinator and "corporatewide_meu" team). If you must insist, how can we compensate for the slight loss of project freedom, since two programs (server.js and routes/index.js) will be strictly controlled the central coordinator.

In order to see some examples of non-intrusive services from the company which will benefit the project teams, let's consider the following four index.js programs to be maintained by the respective project teams.

     routes/
          one_corporatewide_menu/index.js
          two_ecommerce/index.js
          thr_marketing/index.js
          six_cms/index.js

Each index.js program can start with the following inclusions;

     var usehtml = require('../../server').usehtml
     var usejade = require('../../server').usejade
     var useejs  = require('../../server').useejs
     var usehbs  = require('../../server').usehbs

Voila! The UI designer of each project can use his/her favorite template engine, like Jade, Mustache,EJS, Hogan, and Handlebars.

From the company business perspective, with just one server.js program and reverse proxies, the company can finally handle all in-coming web traffic looking for different domain names, such as abcbank.com, abcbank.net, creditcard.abcbank.com, investment.abcbank.com, retirementplan.abcbank.com.

Ma, only ony one server.js program for the entire company, bank or school!

How about a productivity gain and productivity monitoring? A scenario. You just hired a hot-shot programmer named Joe for a new hot analytics project. On his first day on the job, you confidently tell him, "Joe, start populating the following four sub-directories with the tool sets your are already familiar with".


     /var/www/company-initiative-1-folder/routes/ten_analytics/index.js
     /var/www/company-initiative-1-folder/model/ten_analytics/*
     /var/www/company-initiative-1-folder/routes/ten_analytics/*
     /var/www/company-initiative-1-folder/public/ten_analytics/*

To discuss this subject further, please write to us at scaffold@docucomm.com. We will forward you the sample code base.