Александр Кит

1. Как сказали, очень круто что это один язык на фронтэнде и бэкенде. Это пожалуй самое основное и ценное преимущество перед многими другими бэкенд технологиями, если вы разрабатываете не просто вэб страничку, а динамическое вэб приложение.
И замечу, что тут даже не важно что это javascript. Именно важно переиспользование модулей и компонент по обе стороны, а также единая "экосистема". Это часто недооценивают, начинают сравнивать разные аспекты например php vs javascript, go vs javascript, но это не столь важно.
2. Ещё раз, язык который используется в ноде, можно использовать для дэсктоп приложений (nodewebkit) и мобильных приложений (phonegap).
3. NodeJS это не только серверные приложения, а также различные консольные утилиты и разные дэв. скрипты.

Если монго будете выбирать, вот пример для [Class](https://github.com/atmajs/classjs). Правда http сервис нужно отдельно писать, но в основном это и так надо, потому что редко можно обойтись CRUD методами, обычно логика поведения посложнее.

// entity/user.js
var User = Class('User', {
    Base: Class.Serializable({
        activity: Date
    }),
    Validate: {
        activity (date) {
            if (date.getFullYear() !== new Date().getFullYear()) 
                return 'Current year expected';
        }
    },
    _id: null,
    activity: null,
    points: 0,
});
// client/user.js
Class.patch('User', {
    Store: Class.Remote('/rest/user/:_id')
})
// server/user.js
Class.patch('User', {
    Store: Class.MongoStore.Single('users', {
        indexes: [ { date: 1} ]
    })
});

// Browser OR NodeJS
var user = new User({
    _id: 'foo',
    activity: new Date
});
user.save().done(() => {});
//
user
    .patch({
        $inc: {
            points: 2
        }
    })
    .done(() => {})
//
User.fetch({ _id: 'foo' }).done(user => {});
User.fetch({ points: '>10' }).done(user => {});

// Server, http endpoint sample
module.exports = atma.server.Service({
    '$post /' (req) {
        var user = new User(req.body),
            error = Class.validate(user);
        if (error) 
            return this.reject(error);
        
        user.save().pipe(this);
    }
})

Вот ещё варианты:

var SuperModule = require('SuperModule');
var start_ = SuperModule.prototype.start;

SuperModule.prototype.start = function(cb){
    var fn = onceDelegate(cb);
    this
        .once('started', fn)
        .once('error', fn)
        ;
    start_.call(this);
};

function onceDelegate(fn) {
    return function(){
        var x_ = fn;
        fn = null;
        x_ && x_.apply(null, arguments);
    };
}


// ИЛИ, если сделать более общим:
function callbackInjector(Ctor, method, events) {
    var orig_ = Ctor.prototype[method];
    
    Ctor.prototype[method] = function(){
        var args = Array.prototype.slice.call(arguments),
            cb = args.pop(),
            listener = onceDelegate(cb),
            imax = events.length,
            i = -1
            ;
        while(++i < imax) this.once(events[i], listener);
        return orig_.apply(this, args);
    }
};

callbackInjector(SuperModule, 'start', ['started', 'error']);

Если ипосльзуется iis, тогда рекомендую https://github.com/tjanczuk/iisnode модуль, тогда за старт и расспределение будет отвечать IIS - где собственно вы как обычно создаете сайты и bindings.

Рекомендую почитать "50 Tips and Tricks for MongoDB". Текста не много, а информации полно. Здесь в ответах немного напутали - то, что у вас под 1ым пунктом - это денормализованная коллекция. Плюсы в том, что за один запрос имеете всю информацию по обьекту, ну а минусы соответственно, что сложно применять правки. А 2ой пункт, это уже нормализованная - и тут всё наоборот. Но главное, это грамотно балансировать между ними, а не выбирать одну из сторон. Структура очень зависит не только от структуры данных, но и того - как мы используем эти данные (какие выборки делать будем) и на сколько важна их актуальность. Пару советов из разных сторон:
- если идете по первому пути - то можете хранить также все подсущности в отдельных коллекциях. Изменяя подсущность, изменяете её в своей коллекции, и не бойтесь писать скрипты для нормализации, которые по крону будут актуализировать основную коллекцию.
- а если по второму, то храните не только `_id` подсущностей, но также часть обьекта, которая всегда будет нужна, что бы минимизировать запросы.

Что касается первого вопроса, я делаю так:

var await = new (require("atma-class")).Await;

self.once("itemlist", await.delegate());
self.once("photos", await.delegate());

await
    .done(function() {
        self.emit("end");
    })
    .fail(function(error) {
        self.emit("error", error);
    });

Расскажу свою историю. Раньше моим идеалом приложения было — толстый фронтенд + тяжелые WCF(asp.net) сервисы. Мы как порядочные разработчики и свой фронтэндовый фрэймворк создали. И радовались до тех пора пока не получили заманчивый заказ, но одним из условий — некоторые клиенты с выключенным javascript. Возвращаться к asp.net mvc не хотелось, так и пришло знакомство с нодой. Переделали немного фронтенд фрэймворк, и теперь все компоненты летают и там, и там. И что интересно, можем ограничивать компонент только фронтэндом, или если он манипулирует важными моделями — то только бэкенд. Ещё хорошим открытием стал для нас iisnode модуль — о всех кластерах ноды, логированиe, рестартаx (или падениях ноды) нам даже не нужно беспокоится, и плюс все работает параллельно с WCF сервисами. Вообщем мы пока что рады как слоны)

операторы

Как видите function call ниже оператора new, и если выделить скобками вашу запись, то интерпретатор делает следующее —

var model1 = (new require('./test/model1'))();

Функция require отработает хорошo, даже не зависимо от какого контекста была вызвана — а последующий function call будет уже в контексте global
self == model1 == model2 == global

Разные решения:

var module = new (require('module'))();
// екзотические варианты -
var module = new require('module').prototype.constructor();
var module = new new require('module')();

Komodo IDE — не встречал ничего лучшего, или просто мало всего на пути попадалось? В любом случае -удовлетворяет всем желаниям) А уже в алфа 7 имеется поддержка node.js: announce

К node.js имею косвенное отношение, но мне всегда казалось, что:

• всеми силами надо избегать выброса исключений, а возвращать статус ошибки
• вызов ассинxорнной функции должен иметь вид:

  asyncFunction(args, function(error, result){})

И теперь, если перевести эти пункты на ваш код:

auth.getUser(req, function(error,user) {
  if (error != null){
    handle(res,error);
    return;
  }
  db.getData(function(error,data) {
    if (error != null){
      handle(res,error);
      return;
    }
  res.write(template.render(data));
});

Проверки исключений здесь, мне кажется, излишни. Слабое место только template.render(data), надо просто проверить или эта функция бросает исключения. И даже если да, то лучше проверить или объект data валидный перед передачей в render. Пока сам придерживаюсь правила, если в функции для ее нормальной работы надо больше 2/3 if-ов, тогда только try..catch. К сожалению, в Яваскрипте нельзя так гибко обращаться с исключениями как в .NET(печальный вздох). Буду тоже рад если, кто то предложит более конструктивный ответ.