Node.JSでのWeb開発：パート1

プロジェクトのハブに関するPRから1週間が経過しました。 「。 このプロジェクトは、JavaScript（Node.JS）のみで平均的なWebプロジェクトを開発する実験として始まったことを思い出してください。 ここで、この実験の結果、得られた有用な経験、レーキがマークされた詳細な地図をコミュニティと共有したいと思います。

エピソード1：始まりの道

次の目標を設定しました。

• Node.JSで通常のWEBプロジェクトを開発することがいかに便利かを理解してください。
• Node.JSでの開発速度を、使用されている他のテクノロジー（私の場合はPHPおよびJava）と比較してください。
• 多数の合成例で遭遇しない落とし穴を見つけてください。
• 完成したプロジェクトの作業を評価します：安定性、ストレスへの抵抗、そのようなプロジェクトのサポートと開発の複雑さ。

このプロジェクトは、Node.JSで本格的なサイトを開発した最初の経験でした。それ以前は、作業プロジェクトのサポートサービスを作成するためだけに使用しました。 このプラットフォーム用のWEBフレームワークを紹介することから始めました。 当時、それらのいくつかがあり、選択肢がありました。 この段階で、PHP、Java、または他の言語と同じ方法でJavaScriptを記述した場合、これは良い結果にならないことを理解する必要があります。 JavaScriptのようなJavaScriptを記述する必要があります。それ以外の場合、なぜそれが必要なのでしょう（ありがとう、Cap）。 したがって、古典的な継承、同期プログラミングなどのさまざまな実装を提供するフレームワークのクラウドをすぐに渡します。 その言語に特有ではない松葉杖。 「真の」-JavaScriptパスを探していて、JavaScriptのPHPポートではなく、それを評価したかったのです。



すべてのフレームワークのうち、選択はExpressに委ねられました 。 過剰な負荷が最も少ないように思えましたが、同時に要件を最も完全に満たし、サードパーティのモジュールで簡単に補うことができました。



フレームワークから、私は次のものが欲しかった：

• MVCアーキテクチャ。
• ルーティング
• DBMSを使用します。
• テンプレートエンジン。
• 多言語主義のサポート。
• マルチスレッドのサポート。
• 最小限のオーバーヘッド。

また、理解が容易で便利なツールである必要があり、さらなる研究が必要な単なる別のテクノロジーではありません。

エピソード2：The Way of the Samurai

テスト例でExpressを少し使って、そのアーキテクチャを理解し、ソースコードを勉強したので、私はすべてのニーズを満たし、不要な機能で過負荷にならない独自のフレームワークを作成することにしました。 自転車-あなたが言う。 経験-私は言います。 システムを理解する最良の方法の1つは、自分でシステムの類似物を開発することです。 フレームワークは開発、デバッグされ、サイトの最初のバージョンはそれに基づいていました。 サイトが立ち上げられ、ポップアップエラーの修正と新しい機能の追加を同時に行いながら、その動作を観察し始めました。

エピソード3：大洪水

当然、最初はサイトの訪問者が非常に少なく、少なくとも何らかの形でその作業を客観的に評価していました。 しかし、数日後、サイトが嘘をついていることがわかりました。 彼は静かに倒れ、ログには疑わしいものは何もありませんでしたが、倒れたのは、他の誰かのロボットでした。 これらの要求は負荷とは呼ばれず、多くのロボットはそのような速度でサイトをクロールしますが、このために落ちるべきではありません。 私はこのサイトを取り上げて、Siegeユーティリティを使用してテストしました。 そして確かに-このサイトはごく少数の並列リクエストでさえ嘘をつきましたが、それは私の期待を完全には満たしていませんでした。 ログは黙っていました。 悲しみは成長しました。 発掘が始まりました。

エピソード4：最初の石

実験を繰り返して、サーバーで何が起こっているかを監視し、問題を発見しました。ノードプロセスが使用可能なメモリをすべて使い果たし、切断またはハングアップしました（http要求の受け入れを停止しました）。 私は、開発中にメモリ消費を監視しようとした予約を作成します。 これは、長時間実行されるアプリケーションで最も危険な瞬間の1つです。 私は余分なクロージャーをしませんでした、varは負けませんでした、一般的に私はきちんと行動しました。 もう一度、コードを並べ替えて、エラーがその中にないことを確認し、率直に言って動揺しました。 そこで修正するのが最も簡単です。 Node.JSのデバッガーは存在しますが 、非常に便利ですが、非同期操作のためNode.JSアプリケーションのデバッグはより困難です。 このすばらしいツールを使用してレベル80に達したわけではなく、リークを計算できなかったことを告白します。 それで私の休暇は終わった。 Node.JSのパワーを習得する時間はずっと短くなり、私はこの問題をより良い時間まで延期することにしました。 結果に満足せず、毎日プロセスを再起動する小さなユーティリティを作成しました。 このような松葉杖では、サイトは4〜5か月働きました。 一方、Node.JSの開発は止まりませんでした。 新しいバージョンが次々と登場し、サードパーティのモジュールも開発され、小児期の病気がなくなりました。

エピソード5：新しい希望

そして今、かなり長い休憩の後、 Node.JSの変更ログに、修正されたメモリリーク（バージョン0.6.6-0.6.7）に関するエントリがありました。 また、バージョン0.6.0以降、 クラスターAPIが安定版リリースに含まれ、不要なダンスを排除していくつかのノードプロセスを開始できるようになりました。 これはすべて熱意を追加し、プロジェクトを新しい角度から見させました。 この時点で、フレームワークのどの部分が使用されていないか、そこに何が欠けているか、そして便利ではないことをすでに見ています。 さらに、MySQL（元々使用されていた）をMongoDBに置き換えることにしました。



再び人気のあるフレームワークを分析すると、それらはすべて、概して、「独自に」さまざまなモジュールのアセンブリと小さな改良であり、アプリケーションを構築するための独自のルールを規定していることに気付きました。 これらすべてが、疑わしい賞金を伴うタイトなフレームワークに押し込まれます。 個別のモジュールを更新する必要があり、フレームワークがそれと競合する場合、開発者によって更新されたバージョンが追加されるのを待つ必要があります。 または、このフレームワークがサポートしていないモジュール、たとえば、お気に入りのテンプレートエンジンを使用する場合。 どうする サポートを分岐して追加し、フレームワーク開発者がプルリクエストを受け入れるのを待っている間に更新を手動でマージしますか？ いや！



モジュラーシステムNode.JSでは、フレームワーク（読み取り-既製のモジュールアセンブリ）を使用するのではなく、モジュールを直接操作できます。 同時に、フレームワークでラップするのではなく、追加の機能を別のモジュールで使用する必要があります。 このアプローチにより、システムの柔軟性が大幅に向上し、コードの再利用が向上します。



それで、プロジェクトのリファクタリング計画を得ました。 次の項目で構成されていました。

• フレームワークの使用を拒否し、モジュールの直接使用に切り替えます。
• 私の問題を解決するのに最適な膨大な数のモジュールから選択してください。
• MySQLをMongoDBに置き換えます。
• いくつかのプロセスの起動を整理するために、ノード使用（現在はネイティブ） クラスターAPI 。

さらに数日休み、計画が実行されました。 すべてがスムーズに進み、コードの量が減り、アプリケーションの構造がより理解しやすくなりました。 すべてがテストされ、起動する準備ができています。 その後、Habréに関するPR記事を公開し、待ち始めました。

エピソード6：エピックワイン

「habraeffect」が巨大だったとは言えません。 わずか数千人が来ました。 数時間後、サイトがクラッシュしましたが、負荷のせいではなく、私のミスが原因でした。 はい、はい、届きにくい場所で、変数名にタイプミスをしました。これが失敗の理由でした。 それ以外の場合、問題は発生しませんでした。 ページは非常に迅速に与えられ、プロセッサは負担をかけず、メモリは流れませんでした。 1週間、ノードを再起動していないため、サイトは引き続き安定して動作します。 そのような結果は、以前の悲しい経験の後、非常に楽しいです。

結論

JavaScriptのためだけにJavaScriptを書くことはできません。 かっこいい/新しい/人気のある言語（適切な下線）を選択するのはばかげています。 私たちは、テクノロジーから何を望み、それが私たちに何を与えることができるか、そしてそれが見返りに何を求めるのかを明確に理解する必要があります。 私の主な仕事は、これらすべての「Whats」を特定し、「Node.JSは平均的なWebプロジェクトの開発に適していますか」という質問に対する答えを得ることでした。 私の答えはイエスです、そうです。 しかし、他の技術と同様に、直面しなければならない困難があります。 多分、マイナスから始めて、肯定的なメモで終わります。

ヒューストン、問題があります

-1

Node.JSで開発する際に最初に遭遇することは、すぐに使用できる本格的なIDEがないことです。 もちろん、EclipseおよびNetBeans用のプラグインがあり、他のIDEでも部分的にサポートされています。 しかし、現時点では完全なソリューションと呼ぶことは不可能です。 Cloud9 IDEの非常に有望な開発があります。 ブラウザでJavaScriptを直接開発するためのIDEです。 このIDEは急速に開発されており、すでに多くのNode.JS開発者によって積極的に使用されていますが、同時に、私の主観的な意見では、小さなモジュールを作成するのに非常に便利ですが、大規模なプロジェクトで作業する準備がまだ整っていません。 プロジェクトの作業中に、複数のIDEを変更しました。 私はメモ帳++から始め、Cloud9 IDEを長い間使用し、他の人を試しましたが、その名前はもう覚えていませんが、最終的にはNetBeansに戻りました。 Node.JS APIのサポートはありませんが、純粋なJavaScriptを使用すると便利です。 まだ待っており、完全なサポートの出現を期待しています。 このようなプラグインの開発はすでに進行中です。

-2

2番目の不快な瞬間は、各変更を行った後にアプリケーションを再起動する必要があることです。 このプロセスを自動化するユーティリティが存在しますが、これを行うにはまだ時間がかかります。 PHPの場合と同様に、変更を加えてすぐに結果を確認することはできません。 ただし、アプリケーションは非常に迅速に再起動します-使用するモジュールに応じて、1〜数秒です。 Node.JSは間違いなくJavaのパフォーマンスを上回っています。深刻なWEBアプリケーションの再起動にはかなり長い時間がかかります。

-3

初心者のNode.JS開発者が直面する次の問題は、おそらくメモリリークです。 メモリは常にどこでも監視する必要がありますが、高速で動作するPHPスクリプトまたは小さなクライアント側のJavaScriptは非常にリラックスできます。 そのようなアプリケーションでは、多くの開発者は数キロバイトのメモリの損失を特に評価せず、一部の開発者はこのインジケータをまったく監視しません。 Node.JSはそのような譲歩を行いません。 Node.JSのアプリケーションは長時間動作し、リークが発生した場合、サイトへの各リクエストにより、非常に迅速に終了するメモリの一部が削除され、既知の結果につながります。 JavaScriptの特異性は、このタイプのエラーも促進します。 大きなスコープでの1つの余分な短絡または1つのvarの損失により、忘れられない時間のデバッグが可能になります。 しかし、これにはプラスがあります-そのような経験は、他の言語でプログラミングするときに、開発者がメモリを評価し、その使用を制御するようにします。 個人的には、この機能をマイナスとは考えていません。

-4

不都合なもう1つの機能は、非同期コードからのエラー戻りです。 比較のために、PHPでは、すべてのコードが同期的に実行されるため、try-catchコンストラクトを使用して、任意のネストレベルでエラーをキャッチできます。 コントローラーの作業をラップすることができます。例外的な状況の場合は、投げるとエラーが「ポップアップ」されて、それを待っているハンドラーに表示され、ユーザーに美しい恥のページが表示されます。 JavaScriptにはtry-catchコンストラクトもあるという事実にもかかわらず、それは私たちを助けません。 ほとんどのコードは非同期に動作します（I / O）。 この場合、原則として、メソッドが呼び出されたときに例外的な状況は発生しませんが、コールバックが機能するときは、すでにtry-catchコンストラクトの外部で実行されています。 エラー情報をNode.JSに渡すには、通常、コールバック関数の最初のパラメーターを使用します。 つまり エラーが発生した場合、コールバック関数を、それを記述する1つのパラメーターで呼び出すか、最初のパラメーターをundefined / nullに設定し、次に機能の結果を渡します。 実際のアプリケーションでは、呼び出しのネストは非常に大きくなる可能性があり、毎回エラーを渡すのは非常に不便です。 AOPを適用することで問題は解決できると思いますが、このトピックはこの記事の範囲外です。

-5

非常に頻繁に実稼働サーバーに到達する最も単純なエラーも、あなたを緊張させます。 cluser apiが使用されている場合、非常にまれに実行されるコードブロック内の変数名のタイプミスにより、サイト全体またはプロセスの1つがシャットダウンされる可能性があります。 このようなトラブルを回避するには、アプリケーションを監視し、必要に応じて再起動するユーティリティを使用できますが、実際の忍者はコードを適切にテストします（サードパーティのモジュールのエラーに対して誰も安全ではありません）。

-6

最後に追加したいのは、複雑な数学的計算はNode.JS用ではないということです。 このトピックについては、ハブには既に非常に燃えるようなトピックがあり、そこに書かれているすべてを繰り返すことは意味がなく、私はそれについてのコメントを見ていません。 トピックの作成者（もちろん、翻訳ではなく原作者の作成者）が技術の選択に問題があるか、それが単なるトロールであるとしか言えません。 Node.JSでは、イベントループの数ターンにわたって実行される短い反復にタスクを分割することにより、複雑な数学計算を実行することは可能ですが、これはすでに倒錯と狂信です。 そのようなタスクをイベントループの範囲から外したり、開発用に別のテクノロジーを選択したりすることもはるかに簡単です。

これは何のためですか？

この時点までにそのような質問がなかった場合は、経験豊富なJavaScript開発者か、検索ロボットか、Chuck Norris（hello Chuck！）のどちらかです。 他のすべての人のために、Node.JSでのWEBプロジェクトの開発がもたらすメリットを説明しようとします。

+1

Node.JSの最も重要な利点は、非同期の入出力と、それを使用した作業の透明性です。 ほとんどのWEBプロジェクトでは、最も一般的な操作はデータベースからのデータの読み取りと保存です。 通常、同じ操作が最も遅くなります。 しかし、常に遠く離れて、それらはお互いに依存しており、反対に、ほとんどの場合、それらはアトミックです。 たとえば、記事に新しいコメントを追加する場合、次が必要です。

• コメント自体を保存します。
• ユーザーを更新します（たとえば、ユーザーのコメント数と最後のコメントの日付）。
• 記事を更新します（ユーザーの更新と同様）。
• クエリ結果を記録します。

これらの操作はすべて互いに独立しており、DBMSはそれらを同時に実行できます。 たとえばPHPで同期的に実行される場合、これらの操作は、前の操作が完了するのを待つたびに順番に実行されます。 Node.JSでは、これら4つのリクエストすべてをDBMSに「並行して」送信する機会があります。 実際、リクエストは引き続きシーケンシャルに送信されます（そのため、引用符で「並列に」という言葉を引用しました）。 Node.JSは1つのプロセスで動作します。 ただし、Node.JSは、前のリクエストの結果が次のリクエストを送信するのを待ちません。 操作の時間と比較して、要求を送信する時間は無視できます。 要求が実行されると、コールバック関数が呼び出されて結果が処理されます。 これらの呼び出しは、リクエストの送信と同様に順次発生し、その結果は実行時間よりも比較にならないほど高速に処理されます。 したがって、データを使用した合計作業時間は、最長のリクエストの作業時間+リクエストを送信して結果を処理するための小さなオーバーヘッドにほぼ等しくなります。 ただし、いずれの場合も、シーケンシャル処理中のすべてのリクエストの実行時間の合計よりも高速になります（この場合、リクエストを送信して結果を処理するためのオーバーヘッドも発生しません）。

+2

2番目の非常に楽しい機会は、要求ロジック全体の完了を待たずに、準備ができ次第、クライアントへの応答を送信できることです。 前の例に戻りましょう。 コメントを追加するとき、データベースにログを書き込みます。 この操作は必要ですが、ユーザーは応答を受け取るためにこの操作を必要としません。 Node.JSを使用すると、回答を生成して送信し、必要なもの（ログの書き込み、キャッシュのクリアなど）を完了できます。 ユーザーのレイテンシーはそれに応じて減少します。

+3

3番目のプラス要因は、サーバーとクライアントで同じ言語を使用していることです。これにより、一部のコードを再利用できます（フォーム検証、クライアントでのテンプレートの作成など）。 そして一般に、特にアプリケーションのクライアント部分が複雑で、ボタン上のいくつかのイベントを処理するのではなく、深刻な作業を必要とする場合、開発を大幅に簡素化します。

+4

Node.JSプロセスは長期間存続し、すべてのhttp要求を内部的に処理します。 これは、たとえばPHPのように、新しいリクエストごとに初期化が実行されないことを意味します。 設定が読み込まれ、データベースとキャッシュへの接続が開かれ、コードがコンパイルされて準備完了です。 このアーキテクチャと柔軟性のおかげで、JavaScriptはさまざまな最適化手法の大きな範囲を提供します。 たとえば、テンプレートを調べたら、入力を受け取り、すぐに使えるHTMLを返す関数の形式で保存できます。 または、最も頻繁に使用されるデータのローカル（プロセス用）キャッシュを簡単に整理できます。これにより、memcachedと比較しても、データの操作速度が向上します。 はい、PHPには、初期化プロセスを部分的に加速するソリューションがあります-op-codeのAPC、FastCGIでの持続的接続のサポートなど。 しかし、加速された初期化プロセスを原則としてその不在と比較する場合、ゲインは常に後者になります。

+5

Node.JSの周辺では、その比較的短い寿命のために、数百のモジュールとそれに応じて開発者を含む強固なエコシステムが既に形成されています。 主にgithubの利便性により、コミュニティはこのエコシステムの開発に優れたツールを備えており、これは大きな進歩を遂げており、誰でもこの開発に貢献できます。 Node Toolboxやnpmなどのツールを使用すると、必要なモジュールを見つけて選択し、インストールするプロセスが迅速かつ簡単になります。

+6

JavaScript言語自体とNode.JS APIは非常に柔軟で簡潔です。 プログラムはコンパクトで読みやすいです。 ほぼ完全にゲッターとセッター、またはインターフェイスの説明を含む数十のファイルで構成されるクラスが表示されることはほとんどありません。 クロージャーやラムダ関数のようなものを使用すると、非常に美しいコードを書くことができますが、開発者の特別な才能があれば、それを地獄の枝に変えることができます。

JavaとNode.JSのパフォーマンスの比較を見た後、私は長い間笑いました。 ここでは、さまざまな議論や議論を長い間行うことができますが、私が思うに単純に言います。 イベントループで、同時にプログラムコードが数十倍になった場合、このパフォーマンスをひねりました。 Java + Spring Framework + Hibernateで大規模なWEBプロジェクトを開発した経験があります。 11行目が何をするかをうまく説明する10行のコードがあります。 もちろん失礼ですが、おおよその状況を反映しています。 おそらくいくつかのクラスのタスクではこれは関連しますが、平均的なWEBプロジェクトには関連しません。 「Hello world」に関するこのような比較は、実際の状況を反映していないことを付け加える価値があります。 データベース、キャッシング、およびシステムの他のコンポーネントと連携するアプリケーションロジックの出現により、テクノロジーの不完全さよりもテクノロジーの最適でない使用により、ブレーキをキャッチする可能性が非常に高くなります。 さらに、次の2つの場合にはサーバーリソースが十分でない可能性があることに注意する必要があります。

• コードは不完全に書かれています。
• サイトのトラフィックは膨大です。

最初のケースでは、コードとテクノロジーのその後の書き換えで手を伸ばすだけでは何の関係もありません。 第二に-あなたはすでに別のサーバーを購入するのに十分なお金を持っています、なぜなら 数十倍のコードをサポートするよりも経済的に利益があります。

おわりに

Node.JSは魔法の杖ではありません。 これは長所と短所を備えた強力なツールであり、必要な場合にのみ使用してください。 実験の結果に満足しています。 プロジェクトは高速で、開発と保守が簡単なシンプルで明確なコードを持っています。 いくつかの欠点はありますが、Node.JSはWEBプロジェクトの開発に便利であり、この方向での開発を信じています。

続く

第2部では、アプリケーションアーキテクチャにさらに詳しく焦点を当てます。 使用したモジュールと、それらの間の相互作用がどのように構成されているかを説明します。



それを読んだすべての人に感謝します。 コメントにご意見やご意見をお待ちしております。