Я в данный момент пишу приложение для социальных сетей на Node.js.
|
Цитата:
|
А я пытаюсь доказать себе, что на ноде можно делать простые сайты, а не только как AJAX-бекенд.
Вообще если честно я не понимаю, почему говорят что нода для этого плохо подходит. Асинхронность вспоминают при этом, хотя каким она вообще боком на это влияет? Пока никаких трудностей не возникало... |
а оно запросы случайно не в одном потоке обрабатывает?
|
Цитата:
|
Gozar,
Приложение игровое. Был выбран Node.js потому что мне так удобнее, меня устраивает производительность v8 (судя по тестам на сайте апачи, например) и реализация некоторых библиотек (mongoose, socket.io). К тому же разделение по игровым серверам у меня делается через pub/sub от redis сейчас, но поменяю на MQ какой-нибудь скоро, если не будет устраивать производительность. В общем, мне почти нечего сказать кроме того, что проблем почти нет. Цитата:
|
Цитата:
Цитата:
Цитата:
|
Я не использую фреймворки.
Я сделал так: Перед нодой поставил nginx. Конфиг: Код:
// Запросы на неизвестные поддомены отправляем на сервер 404
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"), иначе ответ может быть принят браузером не полностью. |
Цитата:
|
Цитата:
Цитата:
Цитата:
Цитата:
|
B~Vladi,
У вас эти сервера запускаются на разных портах, а из nginx к ним прокси пасс с субдоменов. Т.е. фактически это максимум можно назвать виртуальными хостами. Но внутри сервера вы как выбираете, какой код будет запускаться, вот у меня например было что-то такое:
Framework({
"/upload/(\s+)": {
"json": function(id) {
return false;
},
"html": {
"get": function(id) {
this.error(404);
},
"post": function(id, postData) {
return true;
}
}
}
});
Ну это очень примерно. |
Так:
module.exports = function(request, response) {
var serviceName = request.url.match(/^\/([^/]+)/);
if (serviceName) { // URL состоит из: domain.ru/serviceName/serviceData[/./././]
serviceName = serviceName[1];
if (serviceName != 'index' && SERVICES.hasOwnProperty(serviceName)) {
SERVICES[serviceName](request, response);
} else { // Если запрос приходит на неизвестный сервис, вызываем код сервера ошибок
request.headers.error = 404;
LIB.server.error(request, response);
}
} else { // Если имя сервиса отсутствует, вызывается сервис index (главная)
SERVICES['index'](request, response);
}
};
module.exports.port = 8001;
// Инициализация сервисов. Так же оформенны в виде модулей.
LIB.fileSystem.readdir(CONFIG.path.services, function(err, files) {
var length = files.length;
while (length--) {
var serviceData = files[length].match(/^([^\.]+).js$/);
if (serviceData) {
SERVICES[serviceData[1]] = require(CONFIG.path.services + '/' + serviceData[0]);
}
}
});
Этого вполне достаточно. А о каких проблемах роутинга речь? |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
Недавно на GDD с одним знакомым PHP-кодером состоялся примерно такой диалог: Я: Я проект на ноде делаю. Он: Нода же не для этого? Под неё можно только чаты писать. Я: Почему? Он: Ну там же асинхронный код, коллбеки везде? Я: Ну и что? Он: Ну как ты будешь писать сайт в асинхронном стиле? Это же сложно? Я: Ну да, сложнее чем синхронный. Берёшь руками и пишешь. Главное шаблонизатор хороший иметь. В общем он так и не согласился со мной и аргументов никаких конкретных не назвал. Мне и самому интересно, почему же он плохо подходит. |
Цитата:
|
А как Вы относитесь к реляционным БД в mySql?
Или лучше NoSql? |
Цитата:
|
Цитата:
|
Сори, я хотел написать в node
x-yuri, не всегда. Но в каких случаях, лучше использовать mySql или например MongoBD |
|
Цитата:
в MongoBD нехватало функционала, потому приходилось извращаться. код представлял из себя адовую смесь перла+js+json+монги. мапредьюс там тормазной и не полностью реализован, редьюс делается на мастере. с индексами там тоже проблемы, составные индексы както странно себя вели и в итоге стали использовать индекс по одному полю. кстати индексы задаются хешом а не массивом тоесть {name: 1, age: 1} , это непривычно странно, так как стандарт js не гарантирует последовательность параметров в хеше. в MongoBD много магии, сырой и довольно странный API . |
возможно неподходящая задача или неподходящая реализация, все же mongodb - нереляционная БД и как бывает с ЯП, можно по инерции неправильно ее использовать.
Цитата:
|
Цитата:
PHP для меня основной язык программирования, что не мешает мне извращаться на нем в асинхронном стиле, причем успешно. О Node.Js: что мне нравится в этой модели, кроме асинхронной обработки, и ништяками производительности в связи с этим, так это то, что процесс имеет глобальную область, позволяющую эффективно кешировать куски кода, и результаты функций, и использовать при генерации многих страниц. В стандартной же модели web-а, процесс отвечает за отрисовку только одной страницы, и кешировать может только вовне. Это всегда медленней, чем глобальный объект кеша в рамках процесса. Надо украсть идею, и написать свой Node.PHP =))) |
Цитата:
Если нет, то какое-то другое решение есть, но вроде PHP там безбожно течёт, т.к. не приспособлен под такое. |
x-yuri, когда речь о MongoBD так всегда и говорят. не та задача и не так готовите.
мапредьюс должен распределяться по кластеру. а у них свертка делается на мастере. |
Цитата:
там концепция в том, что отработавший процесс(обработавший 1 запрос) можно не убивать, а заставить обработать еще запросы. При этом в каждый момент времени процесс думает только о нуждах одного запроса, и не начинает думать о новом запросе, пока не закончит старый. Короче, это просто расширение CGI, позволяющее сэкономить на создании нового процесса, и все. Никаких переменных между запросами не перекидывается, и каждый из них начинает с чистого листа. Цитата:
Но, я не знаю о каком решении вы говорите, и если вы не вспомните название, то обсудить точно не получится. |
Цитата:
|
Я импользую mongodb, но у меня не будет увеличения объема данных, а самые оперируемые данные кешируются в memcached.
|
Цитата:
|
CouchDB не знаю не пробовал. Они же мутят что-та новое, отсюда непонятно будут ли развивать CouchDB.
|
CouchDB хуже, чем MongoDB почти во всем.
Цитата:
|
Цитата:
Цитата:
Цитата:
|
наткнулся сегодня
Episode 1 - Mongo DB Is Web Scale |
| Часовой пояс GMT +3, время: 14:04. |