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

Сохранить скрипт/html в utf-8

1) У Вас в search.period_start и search.period_end всегда текущая дата_время "new Date().toISOString()", поэтому ничего и не "ищет" ("new Date().toISOString(req.query.period_start);" - так не работает).
Проще с клиента тогда присылать преобразованные даты (.toISOString) и на сервере подставлять как есть.
2) В базе даты лучше хранить в Date-формате, а не в текстовом.

Здесь https://vk.com/nodejs_dev_group

mayorovp - да по логике все верно я так сразу и сделал. Но так тоже не заработало...

app.get('/', function (req, res) {
    async.parallel([
        function () {
            ...
        },
        function () {
            ...
        },

    ],function () {
        res.send('test');
    });

})

Такого рода решений не встречал. Но есть опыт с E-commerce, поэтому могу вам посоветовать создать свое решений для своего интернет-магазина, так как за все время работы с E-commerce готовое решение никогда не решало нужных задач и не давало возможности для масштабирования проекта

чем Angular отличается от socket.io?

Да всем. AngularJS - фреймворк, базовый каркас вашего приложения, директивы, DI и т.д. socket.io - библиотека для реализации взаимодействия с websockets.

То есть правильно было бы AngularJS + socker.io + express.js. Angular для фронтэнда чуть что. express.js для бэкэнда (rest), socket-io - websocket сервер. Можно использовать сокеты как транспорт для данных если у вас часто взаимодействие с сервером происходит, можно только для push сообщений...

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

То есть если у вас есть куча однотипных запросов с кучей джойнов данные для которых обновляются редко а выборки происходят часто, то тогда можно вооружиться монгой а делать коллекции как агрегации этих выборок. Если вы вставляете референсы и пытаетесь эмитировать джойны в монге то значит вы сделали не правильный выбор основного хранилища данных). Правда денормализовать данные можно и с RDBS....

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

Попробуйте грузить шаблоны на мастерпейдже. Тогда на момент старта js у вас уже будут все шаблоны. У вас явно есть какие-то тяжелые библиотеки. Например, jquery. Их можно не собирать, а грузить с CDN.

Далее, раз у вас есть 8-10 модулей, то лучше соберите их отдельно друг от друга.

Однозначно NodeJs. Соглашусь с предыдущим комментарием, VDS, и нефиг парится )

На баш, срочно.

— Ненавижу лапшу из колбеков. Не представляю как можно писать что-либо серьезное на JS не используя Фреймворки, которые хоть как-то имитируют синхронность. На худой конец jQuery. Если node.js близок к нативному JS, будет сложнее. Либо придется искать фреймворк для него.

Чтобы не было лапши из колбеков, в простых случаях достаточно просто использовать именованные, а не анонимные колбеки. В сложных случаях — async. Node.js близок к нативному JS. Но на всякий случай есть 30000 пакетов в npm.

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

Если у вас будет много синхронных задач, то Node.js не лучший выбор.

— ПХП нравится за кучу встроенных функций (работы с массивами, строками, БД, обработкой картинок и т.д.). Если в ноде в
функционал уровня ES4 и тупо нет библиотеки, чтобы ужать картинку на сервере не будет ли это слишком плачевным?

В ноде нет ничего. В npm есть все. ES5.

— Так ли страшен черт как его малюют. Понятно зачем нужна асинхронность на клиенте. Но на сервере? Только БД и связь с другими серверами (если такое встречается в реальной жизни). Может быть есть способы оптимизировать это и без асинхронности? Может быть ПХПшники через пол года придумают?

А что еще, собственно, делает бэкэнд веб-приложения? Число пи до миллиардного знака расчитывает?

Вывод — все в порядке, используете node.js.

Я бы Вам не рекомендовал использовать ноду для простых проектов.
Нода хороша при хайлоаде и задач где нужен реалтайм.
А вот с наличием модулей для простых сайтов уровня joomla туговато, как и с хостингом.
Хотя, конечно, за нодой будущее, ИМХО.

наши техники/монтажники уже года три в любую погоду и температуру на чердаках и в подвалах используют нетбуки, а именно asus eee pc 701 и 901.