Я в данный момент пишу приложение для социальных сетей на Node.js.

Если можно, то подробнее. Почему был выбран Node.js для этого, с чем сравнивался при выборе и что за приложение(тип)?

А я пытаюсь доказать себе, что на ноде можно делать простые сайты, а не только как AJAX-бекенд.
Вообще если честно я не понимаю, почему говорят что нода для этого плохо подходит. Асинхронность вспоминают при этом, хотя каким она вообще боком на это влияет? Пока никаких трудностей не возникало...

а оно запросы случайно не в одном потоке обрабатывает?

Это что сарказм? В одном потоке, но если я не ошибаюсь то есть вебворкеры и возможность запуска несколько процессов по числу процессоров.

Gozar,
Приложение игровое. Был выбран Node.js потому что мне так удобнее, меня устраивает производительность v8 (судя по тестам на сайте апачи, например) и реализация некоторых библиотек (mongoose, socket.io). К тому же разделение по игровым серверам у меня делается через pub/sub от redis сейчас, но поменяю на MQ какой-нибудь скоро, если не будет устраивать производительность. В общем, мне почти нечего сказать кроме того, что проблем почти нет.

Можно, просто многое нужно будет написать самому, или собирать по кускам. Express.js меня не устраивает почти полностью и целиком. А отдельно вам понадобится даже обработчик multipart/form-data, потому что по-умолчанию в ноде его нет вообще.

В одном, в этом вся прелесть.

Взять нормальный роутер, взять нормальный шаблонизатор, и можно делать.

А чем не устраивает? А то я как раз собрался на него переходить со своего велосипеда.

Я не использую фреймворки.
Я сделал так:
Перед нодой поставил nginx. Конфиг:
Т.е. на ноде мы создаем несколько серверов на разных портах:

var CONFIG = require('config');
var SERVERS_PATH = module.filename.replace(/(.*)\/.*$/, '$1/servers');

var LIB = {
	http: require('http'),
	fileSystem: require('fs')
};

// Create servers
LIB.fileSystem.readdir(SERVERS_PATH, function(err, files) {
	if (err) {
		console.log(err);
	} else {
		var length = files.length;
		while (length--) {
			var serverData = files[length].match(/^([^\.]+).js$/);
			if (serverData) {
				var server = module.exports[serverData[1]] = require(SERVERS_PATH + '/' + serverData[0]);
				LIB.http.createServer(server).listen(server.port, CONFIG.host);
			}
		}
	}
});

Это модуль создания серверов. Рядом в папке servers лежат их реализации:

module.exports = function(request, response) {

};
module.exports.port = 8001;

Например, реализация сервера www (обслуживает основной домен), далее делится на сервисы и, в зависимости от запроса, запускается тот или иной сервис.
Всё вроде логично, функционал разделён. Никаких велосипедов писать не пришлось.

B~Vladi,
Как у вас обрабатывается multipart/form-data и, собственно, загрузка файлов на хост с клиента? Если никак, рекомендую formidable использовать. Быстрая и стабильная библиотека.

Вообще ваша архитектура не очень красива, если честно. Во всяком случае мне она не кажется простой, ведь модули придется располагать на разных портах, значит проблема роутинга у вас не решена вообще.

Кстати, просто на всякий случай, если у вас в сервере передается Content-Length в заголовке ответа, а результат перед выводом строка в utf-8, то значением заголовка должно быть не {String}.length, а Buffer.byteLength({String}, "utf8"), иначе ответ может быть принят браузером не полностью.

Некрасивый он, и по внутреннему коду и по тому коду, что я должен под него писать. Он не очень красиво разбивается на отдельные скрипты, т.е. я не могу сконфигурировать его так, чтобы "контроллеры" я мог удобно выносить в разные модули. У меня такое ощущение, что его писали не рассчитывая, что на нем будут писать что-то большое. А так, это вроде web.py, только на ноде. Так что я написал половину велосипеда, потом бросил, потому что текущие задачи не требуют роутинга через основной сервер (у меня и туда и обратно данные передает socket.io).