これは特に大量のファイルI / Oを処理するのが得意であり、大量のネットワーク通信も適切に処理することが期待されます。ソケット駆動型アプリで特に人気があるようです。覚えておくべき重要なことは、既存のライブラリ（多くある）でニーズが満たされない場合は、JSコマンドにバインドできるCに飛び込む必要があるかもしれないということです。追加のノードプロセスを生成することもできますが、その多くを実行すると、負荷がかかる可能性があると思います（それぞれにV8インスタンスが生成されていると思います-間違っている可能性があります）。
JSはシングルスレッドでブロックされます。つまり、関数呼び出しが完了するまで、他に何も実行できません。これはJSの望ましい機能であり、基本的にすべてのスレッド化とキューイングの懸念を解消しました。JSは、C / C ++の要素が内部でよりマルチスレッドの方法で実行されることを妨げないため、JSの役割は、実際にはより多くのアーキテクチャー/メッセンジャーです。画像処理をしている場合は、同期JavaScriptコマンドでそれを処理する必要はありません。アプリケーションまたはサーバー上の他のすべてが完了するまでブロックされるためです。アイデアは、バインドされたC / C ++機能によって処理される画像を要求し、画像の処理が完了したときに「完了」イベントに応答することです。
これには、任意のNode.jsアプリのJSがイベントとコールバックに大きく依存する必要があります。そうしないと、パフォーマンスが非常に低下する可能性があります。したがって、後で使用するために関数を渡されないNodeのメソッド呼び出しは多くありません。Nodeで非常に速く明らかになることの1つは、コールバックピラミッドを処理する方法を見つけなければ醜い世界にいるということです。例えば
//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 );
} );
} );
幸いなことに、これをよりよく処理するためのツールや例がたくさんあります。ほとんどの場合、promiseメカニズムを中心に展開し、一連の関数を単純にチェーン化して、内部で醜いピラミッドを実行する配列で相互のコールバック状態に応答することを目的としています。
個人的には、ハイレベルのJSとC / C ++をクロームに近づけることが大好きです。これは究極のコンボであり、Cの学習を始めるきっかけになりました。さらに、いくつかの調査を行うまで、ライブラリの欠如の可能性に驚かされないようにしてください。ノードライブラリは非常に速いペースで作成されており、非常に急速に成熟しています。あなたが何もしていなければ、非常に珍しいオッズは誰かがそれをカバーしているのは良いことです。
Railsとの最大の違いは、JSが以前のようにRailsになる可能性が低いことです。私たちはそれを手に入れることができるようにコーディングする傾向がありますが、あなたはそれを非常に迅速に望んでいるので、要因で自分自身をぶら下げるロープがあり、アーキテクチャはより最近までJSでかなりDIYでした。私はそれを自由と呼んでいますが、それは多くの開発者にとって理想的とは見なされていません。
また、Mac以外のものにインストールしようとしたため、Node.jsで「gem」の問題が発生することは決してありません。クライアント側のウェブ開発者は依存関係の問題を軽視し、そこから多くのノードのコアが生まれています。人気のあるすべてのプラットフォームで5分以内に箱から出してすぐに機能しない場合は、通常、それをくしゃくしゃにして投げます。私はそれを機能させるために特別なことをする必要がある人気のあるモジュールにまだ遭遇していません。パッケージシステムは、優れています。
しかし、あなたの核となる質問に、より明確に/簡潔に答えるには：バックグラウンドプロセスで良いですか？
はい。Nodeは基本的に、イベントとコールバックを介してアプリを駆動する手段を備えたバックグラウンドプロセスです。