Node.jsはサーバサイドのJavaScriptインタプリタであり、libeventを基盤としています。Node.jsの目標は、プログラマがスケーラビリティの高いアプリケーションを構築するのを支援することであり、Node.jsの採用の現状は、Node.js公式サイトにいくつかのリストがありますが、かなり不完全です。もしあなたが自分の会社でNode.jsを使っているなら、このドキュメントを更新するためにgithubにプルリクエストを提出することもできます。
私がNode.jsを始めた2011年当時、npmjs.orgのNode.jsパッケージは3,000にも満たなかったのですが、現在では61,897あり、その数は急速に増えています。
1つ目は、Walmartが長年にわたってNode.jsに移行した理由と方法について、2つ目は、eBayがNode.jsに懐疑的な立場から採用する立場へと移行した方法についてです。
qlの発表.io 記事の最後の段落には、eBayがNode.jsを選んだ理由が書かれています。
数行のコードから10,000行のFrameworkまで、毎日何百もの新しいパッケージが npm リリースされています。1日に700万ものパッケージがダウンロードされることは、単一開発者のフレームワークコミュニティにとって、沸騰する海と表現しても過言ではありません。
以下のアプリケーション分野とプログラマは、Node.jsに適していません：
- Javascriptの計算性能は、計算量の多いアプリケーションでは、Cコードに匹敵するのは難しい。もちろん、逆の例もあります。http://...///-----.ml, ただ、典型的な例ではありません。
- メモリ割り当てと解放の正確な制御を必要とするシナリオの場合、Node.jsを使ってRedisデータベースを実装すると、手順ははるかに単純になりますが、メモリ・データ構造の精度を制御するJVMの能力は、純粋に手作りのC言語とは比較になりません。
- Cバインディングを介してCライブラリを頻繁に呼び出す場合。このシナリオでは、ラウンドトリップ・パラメータの Marshal/Unmarshal のコストが、C ライブラリのパフォーマンス向上を上回る可能性があります。
- スイッチや産業用制御ロボットなど、高いリアルタイム性が要求されるシナリオ。というのも、ゴミ収集メカニズムによってメモリを管理するシステムはすべて、GC時に吃驚する可能性が高く、応答性に影響し、最適化が難しいからです。
- 単一のプロセスで大量のメモリを制御する必要があるシナリオ：v8エンジンは設計上、最大ヒープサイズが32ビットで1GB、64ビットで1.7GBに制限されています。 もちろん、node.jsのバッファ確保はv8ヒープ上にないため、この制限を超えることは可能です。この制限は、v8エンジンにmax_old_space_sizeパラメータを渡すことで超えることができますが、GCのパフォーマンス劣化をもたらします。この問題は、ほとんどすべてのGCベースのシステムに存在します。
- システムのスループットを気にしない、あるいは非同期コールを必要としないシナリオ：例えば、複数ユーザーの同時アクセスによるパフォーマンスのオーバーヘッドを気にする必要のない自動化スクリプトなど。Pythonのような "グルー "言語で書く方が簡単です。
- 汎用的でないシナリオ: 例えば、nginx は静的ウェブサーバやリバースプロキシのシナリオ用に特別に設計されており、nginx は Node.js よりも優れたパフォーマンスを発揮します。
- 強力な型付け：Javaや.NETのプログラマーの中には、強力に型付けされた言語や厳密に定義された型システムだけがプロフェッショナリズムの証であり、そのようなシステムを構築するのはアーキテクトの仕事であり、動的言語はデモやフロントエンド開発に使われるおもちゃに過ぎないと考えている人もいるかもしれません。
- コールバック・プログラミングが苦手：Node.jsの非同期IOはコールバックに大きく依存しています。コールバックを使うと、プログラムの実行が2つのパスに見えるようになり、失敗した場合のコールスタックがわかりにくくなります。async、Q promise、その他のパッケージは、この問題を軽減することができますが、学習曲線が急になります。もちろん、たくさん読んだり書いたりしていればの話ですが。より多くの経験が共有されるにつれて、そのプロセスは短くなっています。
その他の分野、または上記のような問題がない分野では、Node.jsがもたらす生産性の向上と安定したパフォーマンスの保証を享受することができます。
パフォーマンス論争
異なる開発環境間のパフォーマンス比較は、常に論争の的となっています。私が言えることは、Node.jsは、ウェブやネットワーク環境向けのアプリケーションを開発する際に、不必要なパフォーマンスの問題を避けるために以下のことに依存しているということです：
- Chrome V8は、Javascriptをスピードのトップクラスに置く、信頼できる優れた仮想マシンです。
- 非同期IOはスレッド数を大幅に減らし、不可解なデッドロックや待ち時間が発生する確率を大幅に減らします。ほとんどの場面で同時実行や同期ロックのことを考える必要がなく、ミスを犯す可能性も低くなります。一方、Pythonでは、非同期IOは標準ではなく、すべてのパッケージに含まれているわけでもないため、アプリケーションが一貫した性能保証を得るのは困難です。
- Node.jsはCore ModulesとUserlandの2つに分かれています。 Core Modulesは非常にコンパクトで、TCP、HTTP、DNS、File System、子プロセス、その他いくつかのモジュールしか含まれていません。コア・モジュールは非常にコンパクトで、TCP、HTTP、DNS、ファイル・システム、子プロセス、その他少数のモジュールしか含まれておらず、ネットワーク・ライブラリは非同期版しかありません。これに対して、Userlandには膨大な数のパッケージがあり、アプリケーションを開発する際には、アプリケーションのニーズに応じてUserlandパッケージを組み合わせることで、非常に低いリソース消費レベルでアプリケーションを実行することができます。実際、私はRaspberry Pi上で数百の同時長時間接続をサポートするWebSockteアプリケーションを開発したことがあります。これは何万ものクラスを持つエンタープライズ開発フレームワークよりも大きな利点です。このアプローチによって、問題が発生する確率、問題を発見するためのコスト、そしてデプロイのコストを削減することができます。
Javascriptにおける絶対的なパフォーマンスの追求は衰えることがありません。Node.jsは、アプリケーションに一貫した予測可能なパフォーマンスを保証するために、その絶対的なパフォーマンスを基盤としています。
Node.jsはJavaScriptの柔軟性を受け継いでいます。
npmjs.orgやgoogleでキーワードを検索できます。似たようなリターンがたくさんあれば、他のパッケージがどれだけそれに依存しているかを見てください。githubに行き、スターやフォークの数をチェックし、issueを読んでください。
有名人」が書いたパッケージならボーナスポイント。
また、鳥を撃つには面倒な方法もあります：
- デイリーjs、エコーjsなど。
- qlの発表.io 、Node.js、Javascript、npmのセクションを含む、オープンソース情報を提供しています。
- asm.js 、ソフトウェア業界の「大きな出来事」や新しいコンセプトを見逃しません。
プロジェクトのリサーチ段階では、何十ものパッケージを閲覧し、そのうちの5～10を読みます。開発プロセスでは、必要な数だけパッケージを見つけ、読みます。
「この巨大な開発コミュニティでは、「標準的な答え」を教えてくれる人はいません。誰もが異なる問題領域や知識背景に直面しているのですから、「標準的な答え」を得ることよりも、より多く読み、より多く試し、より多く考え、新しい知識を得るプロセスを楽しむことの方が重要なのです。
多くの成熟した開発フレームワークがある中で、なぜNode.jsなのでしょうか？
それぞれの特定の問題領域において、誰もが常に最適解を見つけようとしています。Node.jsに代わる他のフレームワークがいずれ登場するように、このプロセスに終わりはありません。
Node.jsの本質的な非同期性は、他の開発フレームワークよりもこのシナリオに適しており、より自然に実装することができます。
これに加えて、Node.jsの設計の基本原則は"The Art of Unix Programming"（Isaac Z. Schlueter's Blog: Unix Philosophy and Node.js）を踏襲しています。
npmとstreamはこの哲学の産物です。
npm
npmはNode.jsのパッケージ管理システムです。パッケージ管理システムは新しいものではありませんが、npmの前身やいとこたちとは異なります：
- npmはNode.jsに直接統合されているため、別途インストールする必要がなく、配布やパッケージのインストールも非常に簡単です。
- npmjs.orgは、各パッケージがどのパッケージに依存しているかを確認できる統合ポータルを提供しており、そのパッケージが誰に依存しているか、最近何回ダウンロードされたかが一目でわかります。githubの更新情報と組み合わせることで、基本的にパッケージがどのようなものであるかの基本的な考えを得ることができます。
- 従来のリリース仕様：git repo.では、ソースコードを直接見つけることができます。README.mdでは、消費者ができるだけ早く使用できるように、簡単な説明を提供しています。
開発者にとって、各パッケージは「マイクロサービス」であり、再利用の最小単位です。ほとんどのパッケージは数百行のコードしかなく、中には数行のコードしかないものさえあります。このレベルの再利用の粒度は、他のコミュニティでは想像もできません。
一口サイズ」のモジュールを書くことは、Node.jsアプリケーションをプログラミングする上で推奨される方法です。これはまた、「企業秘密」の暴露を心配することなく、これらの小さなモジュールをパッケージとしてコミュニティと共有することを容易にします。
npmはすべてのNoderの「ホーム」であり、すべてのNode.jsアプリケーションのシステムアーキテクチャの一部です。
#p#
流れ
npmが「開発時の再利用」のためのメカニズムを提供するのであれば、streamは異なるコンポーネント間の「実行時の再利用」のためのメカニズムを提供します。ストリームのコンセプトはunixのストリームに相当し、アプリケーションの各コンポーネントはunixのフィルタに相当します：
あるアプリケーションで、Webブラウザ、iOSアプリ、ネットワーク上の他のサーバをクライアントに持つAPI Serverが必要です。WebブラウザとAPI Server間の通信は、適切な「フォールバック」を提供する Hacker Newsいます。Web BrowserとAPI Server間の通信は、ブラウザの互換性を考慮した適切な "Fallback "スキームを提供するSockJSをベースとし、iOS App.はブラウザの互換性を考慮する必要がないため、実装が簡単な標準RFC 6455に基づく純粋なWebSocket通信プロトコルを採用し、その他のServerは、ローカルエリアネットワークではTCPを使用し、インターネットではTLSを使用して通信のセキュリティを確保します。
これはNode.jsで実装した方法です：
net.createServer(function(connStream){
dnodeStream = dnode({ func1: function(){} });
connStream.pipe(dnodeStream).pipe connStream;
});
不安定なネットワーク環境での自動再接続の必要性を考慮し、 再接続を追加することもできます。
独自の RPC API の実装ロジックを除けば、これだけ多くの通信プロトコルをサポートするサーバー・フレームワークに必要なコードはわずか 100 行程度で、例外処理もある程度必要です。
tcp、tls、SockJS、reconnectの開発者は "consumer "がそのPackageをどのように使うかわかりません。
さらに、上記の例をもう少し拡張すると、基礎となるStreamを多重化することも可能です：
既存の通信接続用のRPC APIを提供するだけでなく、例えば SockJS分散状態同期機能を追加し、クライアントとサーバ間、サーバとサーバ間の定数データの自動同期を、これらの機能のためのRPC APIを新たに設計することなく完了させる必要があります。 mux-demuxは 、これを可能にします。mux-demuxを使用すると、既存のネットワーク通信Streamを再利用することができ、不必要なネットワーク接続の確立を避けることができます。
ストリームはNode.jsのコア・コンセプトの1つであり、そのインターフェースと動作方法は、異なるコンポーネントが実行時に互いに通信するための最も基本的なサポートを提供するために広く採用されています。
Node.jsでStreamをどのように使うかは、Streamのコンセプトが複雑だからではなく、それらを組み合わせる方法が豊富なので、本一冊分のスペースが必要です。
短い
私が3年前にNode.jsに出会い、学び、採用した主な理由は、Node.jsが今日のWebアプリケーションの問題を解決する上で、高いパフォーマンス、高い信頼性、低消費電力を提供するからです。高性能、高信頼性、低消費電力は、Node.jsが何をするかということではなく、Node.jsが何をしないかということであり、Node.jsとJavascriptのコンセプトは、Javaや他の開発フレームワークにも対応するものがあります。Node.jsとJavascriptの概念は、Javaや他の開発フレームワークにも対応するものがあります。しかし、Node.jsは、最も重要だと考える部分だけをコアモジュールとして保持し、残りをユーザーランドに委ねることで、高性能、高信頼性、低消費電力を最も本質的に保証しています。
Node.jsは過去3年間で進化してきましたが、現在私がNode.jsに没頭し続けているのは、同じ機能ではありません。
npmは「全ては1つのために、1つは全てのために」というコミュニティを構築しており、あなたが入門レベルのNoderであろうと、長年のベテランであろうと、意識的であろうと無意識であろうと、このコミュニティを糧にし、コミュニティに還元しています。npmを使っているうちに、アプリケーションをできるだけ多くのモジュールに分割し、シンプルで簡潔なREADME.mdとともにパブリックパッケージとして公開することが、システムをアーキテクトする上で最も効率的な方法であることに気づくでしょう。
Node.jsが従うUnixの設計思想は、最もシンプルで効果的な再利用仕様を提供します。シンプルさと有効性は意識的な採用につながり、採用すればするほど再利用の可能性が高まります。たとえば、donde 人気のあるMVC Webフレームワークで、コアコードはわずか2,600行強です。
npmとgithubは、今日のソフトウェア制作に新たな制作関係を提供しており、これがNode.jsが現在他のコミュニティを凌駕している根本的な理由です。それは単なるパフォーマンスでも、動的言語でも、Javascriptに精通したフロントエンド・プログラマーの数でもありません。
Node.jsマスター
複雑なバックエンド "が "大規模な継承ツリー"、"強力な型安全性"、"きめ細かい例外定義と処理 "に等しいのであれば、もちろんNode.jsでは扱えません。"であれば、もちろんNode.jsでは扱えません。なぜなら、Node.jsはJavaとは別の「技術ツリー」だからです。プロトタイプ継承、関数型プログラミング、モジュールシステム、コールバック......。プロトタイプ継承、関数型プログラミング、モジュール・システム、コールバック......これらの概念やプログラミング・スタイルは、Javaや.NETに慣れたプログラマーには馴染みがないだけでなく、Node.jsのプログラミング・スタイルにも馴染みがありません。
プログラマーはJavaや.NETで再利用のためのオブジェクト指向やジェネリクスを学びます。しかしNode.jsの世界では、まったく異なるバックグラウンドを持つプログラマーが書いたたくさんのパッケージに触れることで、すべてがクラスではないこと、そして再利用は継承に基づく必要はないことに気づきます。そして、再利用は必ずしも継承に基づいているとは限りません。Node.jsで慣れ親しんだ型システムのクローンを作ろうとしている人がいる一方で、より多くのプログラマがよりエレガントでシンプルな書き方を試しています。Node.jsの開発には「ベスト・プラクティス」はなく、同じような問題に対して常に誰かが別の解決策を試しています。思慮深く内省的なプログラマーにとって、これは楽しいプロセスです。一方、自分で考えたり問題を解決したりしないプログラマーでチームが構成されている場合、Node.jsは適していません。強く型付けされた言語で制約のあるフレームワークを構築し、物理的なチームメイトに空白を埋めてもらう必要があります。
社内にプログラマーは2人しかおらず、そのうちの1人がiOSの開発を担当し、私は「複雑な」バックエンドアプリケーションとウェブブラウザの開発を担当しています。同じ機能をJavaや.NETで開発するには、少なくとも3倍の人手が必要だったでしょう。
Node.jsはフロントエンドとバックエンドを統合できますか？
完全な統一は可能でも必要でもありません。それに、このいわゆる「統一」をNode.jsの頭に置くのではなく、あまりに多くの場面で使われているJavascriptに譲ったほうがいいでしょう。事実を見てみましょう：
- Node.jsはJavascriptでバックエンドアプリケーションを書くことを可能にします。
- Node.jsを使えば、Webブラウザのフロントエンドを書くことができます。一方では、Gruntや他の継続的インテグレーションツールを使って、公開可能なフロントエンドの静的Webサイトコンテンツを生成することができ、他方では、 Scuttlebutt フロントエンドコードにNode.jsモジュールを使うこともできます。
- パフォーマンスに制約のあるモバイルデバイスでも、Javascript Bindingを使ってアプリケーションロジックの一部をJavascriptで実装しながら、UIをNativeの方法でレンダリングすることが可能です。これは多くのゲームですでに行われています。Javascriptが使用される限り、あるいはJavascriptのコードベースが拡大する限り、npmベースのパッケージ管理はBrowserifyを通じて徐々に導入されるでしょう。
2つ目の質問で挙げたようなNode.jsに向かない分野以外では、Node.jsから完全に離れることは難しいです。
Node.jsの行方
もし上司がNode.jsを触らせてくれないなら、青春を失った代償を払わせる必要があります。冗談です :)
Node.jsに投資して損はありません。
貢献に基づいて、フロントエンドとバックエンドの一貫したコードベースが現実のものとなりつつあります。元々バックエンド用に書かれたModuleを使ってフロントエンドを見たり、バックエンドアプリケーションを書くのと同じようにフロントエンドのコードを書くことができます。 ブラウザで本格的なNode.jsを実行する代わりに、必要なModuleをパッケージ化してブラウザにダウンロードするだけで実行できます。
第5問では、Node.jsが分散コンピューティング分野で何ができるかを見てきました。 第8問では、Node.jsがクライアントサイドの開発で果たす役割について見てきました。
私は自分でプログラムを書く「プロダクト・マネージャー」です。1年のうち8カ月は開発に専念し、残りの1カ月は製品設計に費やしています。Node.jsは、自分のおもちゃを組み立てるための数え切れないほどの「レゴブロック」を提供してくれて、とても楽しい経験でした。多くのことを学び、他の人の気まぐれを経験するのに十分な時間がないのが残念です。また、小さな会社は非常にコストに敏感で、Node.jsがなければ、あえて考えもしないようなことがたくさんあります。
