Александр Прозоров

Гуглите темы:

• манифест приложения package.json
  
• параметры пакетного менеджера npm
  

Тут можно вообще обойтись без промисов:

var async = require('async');
var mysqlConnection = ...;

function fetch (param, fetchCallback) { // fetchCallback (err, fetchedData)
    async.auto({

        queryOne: function (cb) {
            // если нет параметра для первого запроса идём дальше
            if (!param) return cb(null, null); 

            // сформировать_sql_запрос
            var queryStr = "QUERY TYPE ONE " + mysqlConnection.escape(param);
            cb(null, queryStr);
        },

        queryTwo: ['queryOne', function (cb, results) {
            // если первый запрос сформирован сразу идём дальше
            if (results.queryOne) return cb(null, null); 

            mysqlConnection.query("QUERY TO GET ADDITIONAL DATA", [...], function (err, data) {
                if (err) return cb(err);

                // сформировать_sql_запрос используя дополнительные данные из data
                var additionalParam = data[0]&& data[0].field || 'An default';
                var queryStr = "QUERY TYPE TWO BY ADDITIONAL DATA "  + mysqlConnection.escape(additionalParam);

                cb(null, queryStr);
            });
        }]

    }, function (err, results) {
        if (err) return fetchCallback(err);

        mysqlConnection.query(results.queryOne || results.queryTwo, [...], fetchCallback);
    });
}

Конструируя запросы с использованием внешних параметров не забывайте про вызов для них mysqlConnection.escape(unsafe_param) чтобы избежать SQL-инъекций.

0) Строку SQL запроса лучше обрамлять двойными кавычками, чтобы спокойно использовать одинарные кавычки внутри запроса для обозначения текстовых констант.

1) Изучите документацию по модулю который используете, там всё описано подробно и доступно.

2) Не вставляйте параметры напрямую в запрос. Никогда.

var T = [1, 2, '3', 4, 5];
connection.query("INSERT INTO `tasks` SET ?", {
  login: req.body.login,
  description: JSON.stringify(T),
  type: 3,
  time: new Date()
}, function(err) {
  if (err) throw err;
});

UPD: а можно даже так

var T = [1, 2, '3', 4, 5];
connection.query("INSERT INTO ?? SET ?", [
  'tasks', 
  {
    login: req.body.login,
    description: JSON.stringify(T),
    type: 3,
    time: new Date()
  }
], function(err) {
  if (err) throw err;
});

То что вы получаете, JSON`ом по сути не является. Формируйте валидный JSON и будет нормально парситься. Значение даты можете передавать либо строкой полученной с Date.toString(), либо количеством миллисекунд посредством Date.getTime();

Тут два варианта. Либо самому парсить, либо используйте Express с его body-parser. Если POST запросы multipart, то тогда смотрите в сторону busboy или connect-multiparty.

Для этих целей используйте библиотеку async. В частности async.each(arr, iterator, [callback]).

Создавать новый процесс для обработки пользовательского запроса, по-сути является шагом назад к протоколу CGI. Это будет медленно и накладно по ресурсам. Собственно поэтому и появился протокол FastCGI, чтобы сократить время отклика за счёт постоянно живущего процесса.

Безотносительно архитектуры приложения, ответить на ваш вопрос сложно. С одной стороны Node рассчитан на долгую жизнь процесса, по крайней мере головного. С другой стороны, реализация web-worker, запуск побочных процессов через spawn и даже в некоторых случаях воркеры в кластере (cluster) вполне могут быть короткоживущими для выполнения разовых задач.

В общем надо плясать от вашей задачи. Очень интересно, что именно заставило вас думать в эту сторону.

После того как gulp запустит node-процесс, весть вывод этого процесса в OUTPUT и так будет вываливаться в консоль.

UPD: речь идёт про запуск node-процесса вот этим таском гульпа, который имитирует работу nodemon.

Стек Backbone.js + Marionette.js очень хорош при для разработки крупных SPA веб-приложений типа ERP/CRM/CMS. Хотя, в последнее время в этой сфере начинает заруливать React, за счёт более лёгкой реализации изоморфного подхода.

Скорость рендера может отличаться потому, что в первом случае express не запущен в production режиме, и не кеширует шаблоны, всякий раз читая их с диска на каждый запрос. От сюда и набегает оверхед. Т.е. при изменении шаблона на диске, вам не надо перезапускать процесс чтобы увидеть изменения в ответе сервиса - это удобно при разработке, но естественно работает медленнее.

В приведённом же вами примере второго способа, шаблон кешируется в памяти процесса в templateFn(). Т.е. при изменении шаблона на диске, у вас ничего не изменится в выдаче пока не перезапустите процесс приложения. По-сути реализуется сразу production mode.

UPD
Попробуйте запустить express-приложение с "обычным" способом рендера задав переменную окружения
$ export NODE_ENV=production
и сравните скорость.

Столкнувшись с такой же как у вас проблемой, отказался от nodemon в пользу вот такого таска:

'use strict';

var node;
var gulp = require('gulp');
var spawn = require('child_process').spawn;

var JS_SERVER_BIN_FILE = './bin/server.js';
var JS_SERVER_SOURCE = './js/server/**/*.js';


gulp.task('supervise', function() {
    gulp.watch(JS_SERVER_SOURCE, function() {
        if (node) node.kill();

        node = spawn('node', [JS_SERVER_BIN_FILE], {stdio: 'inherit'});
        node.on('close', function (code) {
            if (code === 8) {
                console.log('Error detected, waiting for changes...');
            }
        });
    });
});


process.on('exit', function() {
    if (node) node.kill()
});