Он особенно силен в обработке тонны файлового ввода-вывода, и я ожидаю, что он также хорошо справится и с тонной сетевой коммуникации. Это кажется особенно популярным для приложений, управляемых сокетами. Важно помнить, что если ваши потребности не удовлетворяются существующими библиотеками (их много), вам может потребоваться погрузиться в некоторый C, который может быть связан с командами JS. Вы также можете порождать дополнительные процессы Node, но я подозреваю, что выполнение многих из них может обернуться налогом (я предполагаю - может быть неправильно - для каждого из них создается экземпляр V8).
JS является однопоточным и блокирующим, что означает, что больше ничего не может быть выполнено, пока не завершится вызов функции. Это была желанная особенность JS, по сути, убирающая все проблемы с потоками и очередями из ваших рук. JS не останавливает работу C / C ++ от более многопоточной работы под капотом, поэтому роль JS - скорее архитектура / мессенджер. Если вы обрабатываете изображения, вы не захотите обрабатывать их синхронными командами JavaScript, потому что все остальное в вашем приложении или сервере будет заблокировано, пока это не будет сделано. Идея состоит в том, что вы вызываете обработку изображения с помощью связанной функциональности C / C ++, а затем отвечаете на событие «done», когда изображение завершает обработку.
Для этого требуется, чтобы JS в любом приложении Node.js интенсивно обрабатывался событиями и вызывался обратным вызовом, иначе он, вероятно, будет работать очень плохо. Таким образом, вы не увидите много вызовов методов в Node, которые не получают функции для последующего использования. Одна вещь, которая становится очень ясной и очень быстрой в Node, это то, что вы попадете в мир безобразия, если не найдете способа справиться с пирамидой обратного вызова. например
//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
e.fileObj.find('some snippet', function(e){
someFinalCallBackHandler( e.snippetLocations );
} );
} );
К счастью, существует множество инструментов и примеров для лучшего решения этой проблемы. Большинство из них имеют тенденцию вращаться вокруг механизмов обещаний и просто объединять в цепочку ряд функций, предназначенных для ответа на состояния обратного вызова друг друга, в массиве, который делает уродливые пирамиды за вас.
Лично мне чертовски нравится, что мы получаем JS на высоком уровне и C / C ++ ближе к хрому. Это идеальное сочетание, и это вдохновило меня начать изучать C. И не позволяйте отсутствию библиотечного потенциала волновать вас, пока вы не проведете какое-то исследование. Библиотеки узлов создаются очень быстрыми темпами и быстро развиваются. Если вы ничего не делаете, очень необычные шансы хороши, кто-то это покрыл.
Самым большим отличием от Rails является то, что JS вряд ли будет на рельсах, как раньше. Мы склонны кодировать, чтобы иметь возможность иметь его, однако вы хотите его очень быстро, так что есть веревка, чтобы повеситься с фактором, а архитектура JS была довольно самостоятельной в JS до недавних лет. Я называю это свободой, но я понимаю, что это не считается идеальным для многих разработчиков.
Кроме того, у вас никогда не возникнет проблема «драгоценного камня» в Node.js, потому что вы пытались установить что-то другое, кроме Mac. Веб-разработчики на стороне клиента презирают проблемы с зависимостями, и именно отсюда исходит ядро Node. Если это не работает из коробки через 5 минут или меньше на каждой популярной платформе, мы обычно скомкаем это и бросим это. Я еще не столкнулся с популярным модулем, который требовал, чтобы я сделал что-то особенное, чтобы он работал Система упаковки, отлично.
Но чтобы ответить на ваш основной вопрос более четко / лаконично: хорошо ли это с фоновыми процессами?
Да, Node - это в основном фоновые процессы с возможностью управления приложением через события и обратные вызовы.