たとえば、バックエンドにMongo DBがあり、ブラウザーに非常に軽量なJavaScriptが含まれている3層のWebサイトを構築しているとします（フォームの検証、AJAXリクエストを実行するいくつかの凝ったコントロールなど）。
「中間」層のテクノロジーを選択する必要があります（これをサブ層にセグメント化することもできますが、ここではその詳細に焦点を当てるのではなく、テクノロジー全体の選択だけです）。 DB、そしてこれを私がブラウザにプッシュするいくつかのHTMLにレンダリングします。かなり典型的なシンクライアントWebアーキテクチャ。
私の安全な選択は、Javaでこの中間層を実装することです。Jongoなどのライブラリを使用してMongo DBと通信し、Jacksonを使用してJSONをマーシャリング/アンマーシャリングしてAJAXリクエストを行うときにファンシーコントロールと通信します。また、サーバー上でHTMLをレンダリングするためのJavaテンプレートフレームワークもあります。
ただし、次の理由から、これらすべてをウィンドウの外に投げ出し、この中間層にNode.jsを使用するというアイデアに本当に興味があります。
私はjavascript（良い部分）が好きです。このアプリケーションのビジネスロジックでは、Javaよりも表現力が高いとしましょう。
それはどこでもjavascriptです。スタック上のどこで作業する場合でも、言語を切り替える必要はなく、実際にはOOと関数型パラダイムを切り替える必要はありません。階層間に翻訳の配管はありません。JSONはどこでもネイティブにサポートされています。
クライアントとサーバーで検証ロジックを再利用できます。
将来、ブラウザでクライアント側のHTMLレンダリングを行うことにした場合、リファクタリング/再テストの労力を最小限に抑えて、Backboneなどの既存のテンプレートを再利用できます。
この時点でNodeが好きなら、上記のすべてが明白に見えるでしょう。だから私はノードを正しく選ぶべきですか？
しかし...これは私にとっては難しいことです。私たち全員が知っているように、Nodeはシングルスレッドの非同期I /OWebサーバーモデルに基づいています。これは、データの要求を処理するという点でスケーラビリティとパフォーマンスに優れていますが、ビジネスロジックについてはどうでしょうか。テンプレートのレンダリングはどうですか？このようなものは、シングルスレッドのすべてのリクエストに大きなボトルネックを引き起こしませんか？
2つの明白な解決策が思い浮かびますが、どちらも正しくありません。
そこに「ブロッキング」ビジネスロジックを保持し、ノードインスタンスのクラスターとロードバランサーを使用して、リクエストを真に並列に処理します。さて、そもそもNodeがマルチスレッドではないのはなぜですか？それとも、これは常にアイデアでしたか？シンプルな愚かさを保ち、ベースケースでマルチスレッドの複雑さの可能性を回避し、マルチコア処理能力が必要な場合は、プログラマーにこれに加えて追加のセットアップ作業を行わせるのですか？
単一のノードインスタンスを維持し、他のマルチスレッドのアプリサーバーで実行されているビジネスロジックのJava実装を呼び出すだけで、ブロックされないようにします。わかりました。このオプションは、DBへのCRUDリクエストのパフォーマンスとスケーラビリティが向上する可能性を除いて、Nodeの使用についてリストしたすべてのプロを完全に無効にします（実際、Javaを使用するよりも複雑になります）。
これが最終的に私の質問のポイントにつながります-ノードパズルのいくつかの非常に重要な部分が欠けているのでしょうか、事実が完全に間違っているのでしょうか、それともノードがサーバー上のビジネスロジックを処理するのに適していないのでしょうか？言い換えると、Nodeは、データベースの上に座って、I / Oをブロックする他の実装よりもパフォーマンスが高くスケーラブルな方法で多くのCRUDリクエストを処理するのに役立ちますか？そして、妥当なレベルのパフォーマンスとスケーラビリティを維持するために、すべてのビジネスロジックを下の層、またはクライアント側で実行する必要がありますか？
Nodeをめぐるすべての話題を考えると、これよりも多くのことがテーブルにもたらされることを望んでいました。そうでなければ納得したいです！