Да можете конечно, написать свою функцию series, each, parallel не так сложно, и для начинающего конечно лучше сначала свою написать и потренироваться. Но async нужно знать хоть для того, чтоб понимать, какие есть варианты улучшения синтаксиса для асинхронного кода, это только разный синтаксический сахар, можно все на колбеках писать, я предпочитаю так и делать.
Нужны пруфы - делайте сравнительные тесты, мы в команде их делали, но оформлять и публиковать результаты некогда и ничего ни кому доказывать у меня задачи не стоит, доверяете - доверяйте, не доверяете - проверяйте.
только нада не забывать, что 1 сервер на чистой ноде заменит 10 серверов на экспресе, и такая покупка может и не понадобиться, да и масштабирование экспреса ни чем не проще масштабирования нативной ноды
Не только для начала, вообще прежде использования чего-то нужно сравнить это с чистым вариантом по производительности и возможностям. На ноже даже на чистой все кратко и хорошо можно написать, вот еще пример простоты https://github.com/HowProgrammingWorks/EventDriven... Откройте в двух окнах браузера и он через вебсокеты синхнонизирует таблицы, без всяких socket.io и express
ILE -Salim если воркер падает и его нужно перезапустить, то лучше всего, чтобы каждый воркер восстанавливал свое состояние из БД или из файла при старте. Передавать большой массив пользователей из мастер-процесса тоже можно, но тогда нужно хранить его в мастер-процессе для всех воркеров, а это может быть очень много. Ну и мастер тоже может падать, так нельзя положиться на то, что состояние будет надежно сохранено в нем, без БД или файлов не обойтись. В общем, по поводу падений процессов, нужно все так делать, чтобы они поменьше утекали и падали, это не нормально, когда процессы постоянно перезапускаются.
Я вообще не про nginx советова, а про CDN, но отдавать так же. Лучше всего сделать отдельный поддомен для статики: static.yourSiteDomain.com и в зависимости от темы выдавать в html разные css файлы, static.yourSiteDomain.com/themeName/style.css и т.д.
Dinfyru, а как с этим временным хранилищем Вы связываться будете? Варианты такие: Memory-mapped files (файлы отображаемые в память), сокеты, сигналы, IPC. Через IPC могут взаимодействовать только master и worker. Через сигналы нельзя слать данные. Все, только файлы отображаемые в память и сокеты остались. C++ не может быть передатчиком данных, это язык, а не протокол, но Вы можете найти или написать на нем библиотеку, которая будет позволять общаться двум процессам через файлы отображаемые в память, это гораздо быстрее сокетов, но там столько подводных камней, а Вы про это в первый раз слышите, так что, я думаю, что Вы положите год своего времени чтобы получить этот бесценный опыт. Так что, берите сокеты и не страдайте чепухой.
Dinfyru любое соединение между процессами нужно постоянно поддерживать в рабочем состоянии. Сокеты - это один из самых легких способов, можно конечно взять и файлы отображаемые в память, но это тогда вопрос не про Node.js, а про C++.
Alexander Litvinenko: говорит, но еще больше это говорит о багах в ноде, если полистать исходники таких базовых модулей, как cluster или http, то может дурно стать, а другие системы быстро адаптируются под изменения в винде, скорее всего, там изменения в API, но вот nginx же умеет при этих изменениях работать с воркерами по IPC. Думаю, что майкрософты как-то объявляют о таких вещах и нужно следить за их писульками в мсдн или еще где-то, но нода на винду не очень ориентируется, просто всем пофиг.
Alexander Litvinenko: я подробне не разбирался с причиной, знаю только симптом, через IPS (child_process) данные передаются нормально, а вот объекты операционной системы, типа хендлов открытых файлов и хендлов сокетов - не передаются. И это произошло на всех виндах, начиная с 7 (про старые не знаю, наверно они не поддерживаются уже и не обновляются) после установки одного из последних осенних обновлений.
И да, никогда не делайте в винде автообновление, а лучше замените винду на приличную операционку, и ходите в нее только в дуалбут по особой нужде раз в месяц.
Первая статья устарела, берите вторую. В наши дни socket.io уже не нужен, вебсокеты есть везде и их интерфейс удобный и не на много более низкоуровневый.