Какие библиотеки использовать для высоконагруженного приложения в Node.js?

Это будет игра. На сколько я знаю node.js однопоточный, какую магию наложить на него, чтобы он использовал все ресурсы сервера?

Если сервер один, и за его пределы Вы не собираетесь выходит, то все просто https://nodejs.org/api/cluster.html

Тимур Шемсединов: Отлично! Я так подумал, может тогда вместо socket.io использовать Sock.JS? Всё-таки socket.io это некая обертка. Так ведь?

Не нужно ни то ни то, берите просто для вебсокетов на серверной стороне библиотеку https://www.npmjs.com/package/websocket а на клиенте делайте new WebSocket(url) Вебсокеты уже везде поддерживаются без оберток caniuse.com/#feat=websockets Ну и тут посмотрите как на клиенте коротко и удобно все писать https://learn.javascript.ru/websockets Ради Аллаха, ни какие дополнительные библиотеки не тяните за собой.

Можете рассказать подробнее, почему не стоит использовать middleware?

Тимур Шемсединов: Иншааллах, буду использовать только родные! Спасибо)

Все что нода дает, middleware это забирает. Это только основные прощелки этой архитектуры:
1. Тот middleware, который стоит раньше в цепочке, может сделать нечто, что не ожидают идущие после него, например, отправит заголовки, непоправимо изменит состояние соединения и объект запроса.
2. Иметь сотни middleware в цепочке, это убийство производительности и не позволяет сделать высоконагруженные системы на middleware достаточно крупными.
3. Если middleware не содержат операций ввода/вывода, и работают преимущественно с память, то выполнение цепочки middleware не возвращает управления в цикл обработки событий, что конфликтует с асинхронным подходом nodejs.
4. Middleware увеличивает связанность кода, по сути все приложение становится крепко связанным и теряется модульность, потому, что объекты req и res это сквозное для всего кода состояние и общие данные, не изолированные интерфейсами.
5. Нет возможности навешивать нечто на финализацию соединения, т.е. middleware идут по цепочке и если один из них выполнил часть своих действий, то он может через костыли навесить события, чтобы завершить свои действия после всех остальных middleware, но у него нет ни какой уверенности, что другие middleware не изменят что-то или не завершат соединение не передав ему управление для финализации.

Тимур Шемсединов: попробую возразить, пусть и не могу похвастать большим опытом использования мидлвари вообще и нодовской реализации в частности :)
1-3. применимы и к другим способам структуризации кода. То есть выполняемая ранее функция с доступом к http-контексту может его поменять, куча функциональности будет потреблять много ресурсов (ок, мидлваря может съесть больше памяти за счёт вложенных вызовов вместо последовательных), не передать управление в цикл обработки событий тоже можно откуда угодно.
4. Мне кажется, такого можно добиться только если вообще всё пытаться делать через мидлвари. Если куску логики не нужно знать о постах с гетами и прочими заголовками - незачем делать его мидлварей и насильно скармливать req/res :)
5. Тут соглашусь, в таком виде, как это сделано в ноде, нормально решить не получится.

1-3. Если не нанизывать обработчики в цепочки вызовов, а хранить их в хешах, то их и искать быстрее и исполнять все не обязательно и зависимость между обработчиками можно существенно снизить. Простой пример: есть у нас пакет passport (для авторизации через соцсети) и есть HTTP API на 100 методов, так вот этот passport будет для каждого URL в системе выполняться и для всех 100 методов, хотя можно было бы его выполнять только для 2 URL, а именно для URL логина и для URL обратного вызова от соцсети. В результате этот пасспорт жрет производительность, т.к. инициализирует (сволоч такая) свои личные стрктуры данных для каждого соединения и потом передает эстафету.

4. Если такой кусок логики не навешен на middleware, а красиво находится в специальном модуле с бизнеслогикой, откуда экспортируется, то он все раво вызывается с middleware и если в куске логики нет I/O, то ему нужно будет самому заботиться о возврате управления в цикл обработки событий. Это не такой уж умозрительный случай, пример: кусок бизнеслогики делает emit событию, но подписчики его не получат до завершения всей цепочки вызовов, если в middleware не будет написано process.nextTick(next) или через setTimeout. Такое встретить можно повсеместно, так что моногие вообще считают, что лишний раз вызвать nextTick не грешно. Вместо этого если бы обработчики не были нанизаны в долгие цепочки, то nextTick можно было бы вставлять только там, где в бизнеслогие если долгие операции без I/O, а так им приходится злоупотреблять.

5. В ноде сделано все грамотно, в ядре ни где не используется принцип middleware, поэтому специализированные решения на ноде такие быстрые и производительные, а все, где нагадили connect с express`ом все это уже нельзя назвать ни высокопроизводительным, ни гибки, ни красивым кодом. Так что, пишите свои узко специализированные маршрутизаторы запросов, где функции сложены в индексирующие хеши и выбирается 1 функция на каждый URL. Или можно сделать 3 хеша: функции инициализации, функции обработки и функции финализации. И шоб ни одна зараза не сделала writeHead() and end(), а просто отдавали свои данные маршрутизатору, который смотрит, что все готово и отдает ответ. Пилите узко специализированные вещи на ноде, чтобы они были у Вас быстрые, да будет Аллах Вами доволен.

Тимур Шемсединов: так понятнее, спасибо за объяснение.