Разработка WEB-проекта на Node.JS: Часть 2

Разница в скорости работы с мемкешем и без на данном проекте довольно существенная. Хотя это сильно зависит от конфигурации сервера и самих запросов.

кстати, как такие ограничения задать подскажите?

Да, его функционала вполне хватает.

Пример получения данных для страницы «обсуждаемые»:

var hub = require('hub');
/* Тут инициализируются другие объекты нужные модулю, убрал для краткости */

var collection = new hub.mongodb.Collection(hub.mongodbClient, 'message');

/* Тут расположены остальные методы этой модели */

module.exports.findDiscussed = function(page, cb) {
	collection.find({isPublished: true, type: 0, replies: {$ne: 0}}, function(err, cursor) {
		cursor.sort({replyDt: -1}).limit(hub.config.app.perPage).skip(page * hub.config.app.perPage);
		cursor.toArray(function(err, messages) {
			cb(err, messages);
		});
	});
};

/* И тут тоже */

Среди тех модулей, что я привёл выше, что по вашему лишнее? Я не люблю изобретать велосипеды, только в крайнем случае. Вот вы говорите, что используете только шаблонизатор и коннектор к БД. А такие рутинные вещи, как поддержка сессий, разбор multipart-запросов для вычленения из них файлов, удобную работу с куками (они же в нативном виде приходят просто массивом заголовков), роутинг. Вы это с нуля сами пишите? Я не вижу в этом смысла. Я не в коем случае не предлагаю безумно собирать всё подряд и использовать это. Перед тем, как что-либо подключить к проекту я внимательно изучаю его исходный код, чтобы понять как оно работает и не будет ли оно где-то фейлить. Но писать что-то, что уже написано до вас и возможно написано лучше чем вы сможете написать за ограниченное время — смысла не вижу. Лучше сосредоточиться на логике приложения и обеспечить его стабильную работу. Как ни крути — используя сторонние модули это выйдет сделать гораздо быстрее.

1. form <= regexp. В корне не согласен. Я полагаю речь идёт об удобном и лёгком в использовании автоматизированном инструменте, который позволяет проверять формы, наглядно выводить ошибки связывая их с нужными полями. Сам написал для этого велосипед и он получился весьма большим. Да в нём повсюду используются регулярки, но без него для каждой формы пришлось бы писать свой новый велосипед, которые очень сложно поддрживать. Чем больше мне приходится работать со сложными и не очень формами, тем больше я прихожу к выводу, что без мощного и удобного инструмента это нелепая трата времени.

2. localejs <= {}. Аналогично. Я полагаю, что надо привыкать сразу к удобным инструментам, которые сделают за тебя всю работу и будут удобны людям, переводящим сайт.

3. async <=… Не зря же та статья вызвала столько споров. Получается огромный малочитаемый код, который не решил никаких проблем. ИМХО.

Тут есть, что обсудить. Эти утверждения очень субъективны. Я про <=.

Начну с того, что вобще всё пишется относительно легко, когда знаешь как оно работает. Но это не является поводом писать это самому.

async делает разработку более удобной. Если я знаю как он работает и могу написать аналог это не значит что я должен этим заниматься. В статье на которую вы сослались приведена техника распаралеливания довольно похожая на работу async в далёком приближении. Если это начать развивать получится тоже самое.
Но зачем этим заниматься если я могу подключить async и писать код вроде:

async.parallel({
	questions: function(cb) { messageModel.findByTag(tag, page, getQuestions(res, cb)); },
	info: function(cb) { messageModel.countByTag(tag, getInfo(req, page, cb)); }
}, function(err, results) {
	/* Тут я имею в переменной results 2 поля questions и info с готовыми данными или в err ошибку произошедшую во время выполнения */
});

Если он настолько удобен и не ухудшает производительность, в чём проблема?

node-oauth и node-twitter — написание собственных полезно будет только для понимания принципа работы (читать — развития). Потом обязательно будет столкновение с проблемами различия поведения разных сервисов и написание костылей, которые в этих библиотеках уже учтены. Для опыта полезно, для разработки приложения — нет. Если не хватает функционала лучше внести исправление в библиотеку и отправить pull request (ну или развивать свой форк) — пользы для всех будет больше.

http-get. Да пишется это довольно просто. А когда дойдём до определния в ответе gzip-сжатия и следованию за редиректами — получим свой http-get. Зачем?

daemon.node. Тут согласен. Можно использовать strat-stop-daemon и подобные утилиты. Но иногда это бывает не так удобно, как дописать 2-3 строки в приложение. Тут зависит от ситуации.

form — категорически не согласен. Это никак не просто regexp. И тем более не <=. Имея в одном месте довольно простое описание правил для ожидаемого объекта мы передаём обработчику сырые данные и на выходе получаем либо список ошибок либо 100% валидные данные, которым мы можем доверять. Такой подход сокращает тучу проверок в коде контроллера.

configjs и lacalejs — да это {}. Но не просто {}, а с функционалом для решения рутинных операций. Да оно пишется просто. Да — ничего не стоит самому написать эти 50 строк кода. Я один раз написал их так, как мне кажется это удобно использовать, оформил их в модуль и теперь могу использовать их везде просто подключением этого модуля. Мне не нужно хранить его в репозитории проекта. Если я захочу расширить функционал я сделаю это в одном месте и все проекты, где подключен этот модуль смогут просто обновиться при помощи npm и получить доступ к новому функционалу. Разве не круто? Или копипаст наше всё?

hub — правильная структура приложения? С удовольствием почитаю о том, как вы видите правильную структуру приложения. А конкретнее следующие моменты: доступ к конфигурации приложения из любой его точки (контроллеры, модель, фильтры (выполняемые до или после контроллеров), таски. Доступ к пулу заранее открытых соединений с кешем и базой данных из любой модели. Доступ к мультиязычным строкам из контроллеров и шаблонов. И т.д.

connect-response — да это шаблонизатор и методы работы с куками + рутинные операции для формирования ответов (заголовки, коды, редиректы и т.п.). Просто это нужно на всех web-проектах, я не вижу причины не оформлять это в удобный модуль.

Кстати, вы не ответили про роутинг, разбор заголовков, разбор multipart-запросов, поддержку сессий. В нативном Node.JS этого нет и кода это занимает прилично (хоршоая реализация). Как вы делаете это без connect и ему подобных модулей?

Промахнулся. Это ответ на вот этот комментарий: habrahabr.ru/blogs/nodejs/138629/#comment_4629998

Когда количество текстов ошибок будет приближаться к сотне

А вам не кажется, что в проекте что-то не так, если там сотня разных сообщений об ошибках?

4. Я не понял что вы думаете что я имею ввиду. Есть модуль с запросами к БД — findDiscussedQuestions, findUnansweredQuestion и т.п. В этом модуле БД и подключается, и используется.

5. Генерация всех шаблонов всего приложения должна быть в одном месте. А вот подготовка данных для этой генерации — раскидана по «тематическим» модулям. Контроллер дёргает функцию, которая собирает данные, что-то с ними делает и возвращает это контроллеру. Дальше контроллер дёргает генерацию нужного шаблона с этими данными.

Ну и я не про другие языки говорю, а про Javascript в общем и node.js в частности.

Ещё есть полезный dstat.

В node.js утечки могут быть только при ошибках в коде (вашем либо в используемых модулях). Посмотрите весь код внимательно. Места объявления переменных, циклы, рекурсивные функции и т.п.

занятно. Т.е. около 115 запросов в секунду. А в пике сколько? Какого плана запросы? долгоживущие или простой http запрос-ответ?

form.filter(form.Filter.trim) это и есть sanitize. Можно использовать как встроенные фильтры node-validator, так и свои собственные, написанные в формате node-validator.

var form = require('form');

// Свой фильтр в формате node-validator
filterToUpperCase = function() {
    this.modify(this.str.toUpperCase());
    return this.wrap(this.str);
};

var fields = {
    name: [
        form.filter(form.Filter.trim), // Применяем встроенный в node-validator фильтр trim
        form.filter(filterToUpperCase), // Применяем свой фильтр
        form.validator(form.Validator.notEmpty, 'Empty name'),
        form.validator(form.Validator.is, /[0-9]+/, 'Bad name')
    ],
    text: [
        form.filter(form.Filter.trim),
        form.validator(form.Validator.notEmpty, 'Empty text'),
        form.validator(form.Validator.len, 30, 1000, 'Bad text length')
    ]
};

var textForm = form.create(fields);

textForm.process({'text' : 'some short text', 'name': ''}, function(error, data) {
    console.log(error);
    console.log(data);
});