序文
従来のWeb開発モデルによってもたらされるさまざまな問題を解決するために、私たちは多くの試みをしましたが、前端と背面の間の物理的なギャップのために、私たちが試したソリューションは似ています。痛みから学び、今日は「フロントエンドとバックエンド」の定義を再考し、フロントエンドの学生に馴染みのあるNodeJSを導入し、真新しいフロントエンド分離モードを探索しようとしています。
さまざまな端末（PAD/モバイル/PC）の増加に伴い、開発者はますます高い要件を持っています。純粋なブラウザ側の応答性は、ユーザーエクスペリエンスの高い要件を満たすことができなくなります。多くの場合、さまざまな端末用にカスタマイズされたバージョンを開発する必要があります。開発効率を向上させるために、フロントエンドとバックエンドの分離の必要性はますます評価されています。バックエンドはビジネス/データインターフェイスを担当し、フロントエンドはディスプレイ/インタラクションロジックを担当し、同じデータインターフェイスの複数のバージョンをカスタマイズおよび開発できます。
このトピックは最近多く議論されており、一部のAlibabaバスもいくつかの試みをしています。長い議論の後、私たちのチームは、NodeJSに基づいたフロントエンドとバックエンドの分離スキームのセットを探求することにしました。その過程でいくつかの変化する理解と考えがありました。ここに録音しました。また、私が見た学生が議論に参加し、それを改善するのを手伝ってくれることを願っています。
1.フロントエンドの分離とは何ですか？
グループ内での最初の議論の中で、私は誰もがフロントエンドの分離について異なる理解を持っていることを発見しました。彼らが同じチャネルで議論できるようにするために、最初に「フロントバックエンド分離」とは何かについて合意に達します。
誰もが同意するフロントエンド分離の例は、SPA（シングルページアプリケーション）です。使用されるすべてのプレゼンテーションデータは、非同期インターフェイス（AJAX/JSONP）を介してバックエンドによって提供され、フロントエンドには表示のみが表示されます。
ある意味では、SPAはフロントエンドの分離を達成しますが、この方法には2つの問題があります。
Webサービスの中で、SPAは非常に少ない割合を占めています。多くのシナリオでは、同期/同期 +非同期ハイブリッドモードもあり、SPAは一般的なソリューションとして使用できません。
現在のSPA開発モデルでは、インターフェイスは通常、プレゼンテーションロジックに従って提供されます。効率を改善するために、バックエンドがいくつかのプレゼンテーションロジックを処理するのに役立つ場合があります。つまり、バックエンドは、フロントエンドとバックエンドの実際の分離ではなく、ビューレイヤーの作業に依然として関与しています。
スパスタイルのフロントエンド分離は、物理レイヤーとは区別されます（クライアントである限り、フロントエンド、バックエンドがサーバーであると考えてください）。この分類は、フロントエンド分離のニーズを満たすことができなくなりました。責任を分割することによってのみ、現在の使用シナリオを満たすことができると考えています。
フロントエンド：ビューとコントローラーのレイヤーを担当します。
バックエンド：モデル層、ビジネス処理/データなどのみを担当します。
なぜこの責任の分割が後で議論されるのか。
2。なぜ前端と背面を分離する必要があるのですか？
この問題に関して、Yu Boの記事は、Web R＆Dモデルの進化において非常に包括的に説明しています。簡単にレビューしましょう：
2.1既存の開発モデルに適用可能なシナリオ
Yu Boが言及した開発モデルにはそれぞれ独自のシナリオがあり、他のシナリオを完全に置き換えるものはありません。
たとえば、主にバックエンドに基づいたMVCの場合、同期ディスプレイビジネスを実行することは非常に効率的ですが、同期および非同期ページに遭遇すると、バックエンド開発と通信する方が面倒です。
AjaxはメインのSPA開発モデルであり、アプリタイプのシナリオの開発に適していますが、SEOやその他の問題を解決するのが難しいため、アプリの作成にのみ適しています。多くの種類のシステムでは、この開発方法も重すぎます。
2.2フロントエンドとバックエンドの責任は不明です
複雑なビジネスロジックを備えたシステムでは、フロントエンドとバックエンドと混合したコードを維持することを最も恐れています。制約がないため、MVCの他の層のコードが各層に表示される場合があります。時間が経つにつれて、メンテナンスはまったくありません。
フロントエンドとバックエンドの分離はこの問題を完全に解決することはできませんが、大いに緩和される可能性があります。物理レベルからこれを行うことができないことが保証されているからです。
2.3開発効率の問題
TaobaoのWebは基本的にMVCフレームワークWebXに基づいており、アーキテクチャはフロントエンドがバックエンドにのみ依存できると判断します。
したがって、私たちの開発モデルは、フロントエンドが静的デモを書き込み、バックエンドがそれらをVMテンプレートに変換することです。私はこのモデルの問題については話しませんし、私は長い間批判されてきました。
また、バックエンド環境に基づいて直接発達するのは苦痛であり、構成、インストール、使用が厄介です。この問題を解決するために、VMarketなどのさまざまなツールを発明しましたが、フロントエンドはVMを書き込み、バックエンドデータに依存する必要があるため、効率はまだ高くありません。
さらに、バックエンドはディスプレイへの強い焦点を取り除くことができないため、ビジネスロジックレイヤーの開発に焦点を当てることはできません。
2.4フロントエンドパフォーマンスの制限
パフォーマンスの最適化がフロントエンドでのみ行われる場合、スパークを作成するにはバックエンド協力が必要になることがよくあります。ただし、バックエンドフレームワークの制限により、パフォーマンスを最適化するために彗星、BigPipe、その他の技術ソリューションを使用することは困難です。
上記の問題のいくつかを解決するために、多くの試みを行い、さまざまなツールを開発しましたが、主にバックエンドで分割された小さなスペースしか使用できないため、多くの改善はありませんでした。前端と背面を真に分離することによってのみ、上記の問題を完全に解決できます。
3.フロントエンドとバックエンドを分離する方法は？
フロントエンドとバックエンドを分離する方法は？実際、最初のセクションには答えがあります。
フロントエンド：ビューとコントローラーのレイヤーを担当します。
バックエンド：モデル層、ビジネス処理/データなどを担当します。
フロントエンドマスターがコントローラーをマスターしている場合、URL設計を行うことができ、シーンに応じてサーバーでレンダリングを同期するか、ビューレイヤーデータに基づいてJSONデータを出力するかどうかを決定できます。これは、要件によって決定される使用方法です。
3.1 nodejsに基づく「フルスタック」開発
上記の図のレイヤー化を実装したい場合は、バックエンドの前後に何をするかを実現するのに役立つWebサービスが必要になるため、「NodeJSに基づくフルスタック開発」というタイトルがあります。
この写真はシンプルで理解しやすいように見えますが、試したことはありません。多くの質問があります。
SPAモードでは、バックエンドが必要なデータインターフェイスを提供しており、ビューフロントエンドはすでに制御できます。 NodeJSレイヤーを追加する理由
もう1つのレイヤーを追加してみませんか？
もう1つのレイヤーを追加すると、フロントエンドのワークロードが増加しますか？
もう1つのレイヤーを追加すると、別のリスク層が発生します。それを壊す方法は？
nodejsは何でもできますが、なぜJavaが必要なのですか？
これらの問題を明確に説明するのは簡単ではありません。以下の私の理解プロセスについて話させてください。
3.2 Nodejsの層を追加する理由
この段階では、主にバックエンドMVCモデルを開発します。このモデルは、フロントエンド開発の効率を真剣に妨げ、バックエンドがビジネス開発に焦点を当てるのを防ぎます。
ソリューションは、フロントエンドがコントローラーレイヤーを制御できるようにすることですが、すべてのフロントエンドがJavaを学習し、バックエンド開発環境をインストールし、VMを書き込むことは不可能であるため、既存のテクノロジーシステムでそれを行うことは困難です。
nodejsはこの問題を非常にうまく解決できます。私たちは、開発が以前に行ったことをすることができ、すべてがとても自然に思えます。
3.3パフォーマンスの問題
レイヤー化には各レイヤー間の通信が含まれ、特定のパフォーマンス損失が間違いなくあります。ただし、合理的な層別化により、責任が明確かつ共同作業的になる可能性があり、開発効率が大幅に向上します。層別化によって引き起こされる損失は、他の面で間違いなく補償されます。
さらに、拘束することを決定したら、通信方法と通信プロトコルを最適化することにより、損失を最小限に抑えることができます。
例えば：
Taobao Baby Detailsページが静的になった後、ロジスティクス、プロモーションなど、リアルタイムで取得する必要がある情報がまだたくさんあります。この情報は異なるビジネスシステムにあるため、フロントエンドはこれらの内容を埋めるために5つまたは6つの非同期リクエストを送信する必要があります。
nodejsを使用すると、フロントエンドはnodejsでこれらの5つの非同期リクエストをプロキシでき、BigPipeを簡単に実行できます。この最適化は、レンダリング効率全体を大幅に向上させることができます。
PCに5つまたは6つの非同期リクエストを送信しても大丈夫だと思うかもしれませんが、ワイヤレス側では、顧客の携帯電話でHTTPリクエストを確立するのは非常に高価です。この最適化により、パフォーマンスは数倍改善されます。
Taobaoの詳細は、nodejsの最適化に基づいています。私たちは進行中です。起動後、最適化プロセスを共有します。
3.4フロントエンドのワークロードは増加しましたか？
ページ/デモをカットするだけで、もう少しでなければなりませんが、現在のモードにはリンクと通信があります。このプロセスには多くの時間がかかり、バグが生息しやすく、維持が困難です。
したがって、ワークロードは少し増加しますが、全体的な開発効率は大幅に改善されます。
さらに、テストコストを大幅に節約できます。過去に開発されたインターフェイスはすべてプレゼンテーションレイヤーを対象としており、テストケースを作成することは困難です。フロントエンドとバックエンドの分離が行われた場合、テストも分離できます。 1つのグループのグループはインターフェイスのテストを専門としており、もう1つの人々のグループはUIのテストに焦点を当てています（作業のこの部分はツールに置き換えることさえできます）。
3.5ノードレイヤーを追加することでもたらされるリスクを制御する方法は？
ノードの大規模な使用により、システム/操作およびメンテナンス/セキュリティ部門の学生は、間違いなくインフラストラクチャの建設に参加します。彼らは、各リンクの可能な問題を改善し、部門の安定性を確保するのに役立ちます。
3.6ノードは何でもできますが、なぜJavaが必要なのですか？
私たちの当初の意図は、前端と背面を分離することです。この問題を検討すれば、それは私たちの当初の意図に少し反します。 Nodeを使用してJavaを置き換える場合でも、不明確な責任など、今日遭遇した問題に遭遇しないことを保証することはできません。私たちの目標は、階層化された方法で、専門家の人々を発展させ、専門的なことをすることに集中することです。 Javaに基づくインフラストラクチャは、すでに非常に強力で安定しており、現在のアーキテクチャを行うのに適しています。
4。Taobaoのノードベースのフロントエンド分離
上の写真は、ノードの責任の範囲だけでなく、ノードに基づいたTaobaoのフロントエンドとバックエンドの分離と階層化について私が理解していることです。簡単な説明：
上端はサーバーです。これは、バックエンドと呼ばれることがよくあります。私たちにとって、バックエンドはインターフェイスのコレクションであり、サーバーは私たちが使用できるさまざまなインターフェイスを提供します。ノードレイヤーがあるため、どのようなサービス形式のサービスを制限する必要はありません。バックエンド開発には、ビジネスコードを気にするインターフェイスのみを使用します。
サーバーはノードアプリケーションの下にあります。
ノードアプリケーションには、サーバーと通信するモデルプロキシのレイヤーがあります。このレイヤーは、主にさまざまなインターフェイスを呼び出す方法を滑らかにし、ビューレイヤーで必要なモデルをカプセル化するために使用されます。
ノードレイヤーは、元のVMCommon、TMS（Taobaoコンテンツ管理システムを引用）およびその他の要件を簡単に実現できます。
ノードレイヤーに使用するフレームワークは、開発者次第です。ただし、Express + dxtemplateの組み合わせを使用することをお勧めします。これは、フロントエンドとバックエンドに使用できます。
誰もがノードの使用方法を決定しますが、エキサイティングなのは、最終的にノードを使用して、該当する出力メソッドを簡単に実装できることです：JSON/JSONP/RESTFUL/HTML/BIGPIPE/COMET/SOCKES/SYNCHRONOUSおよび非同期。それはあなたが望むことを何でもすることができ、それはあなたのシナリオに完全に基づいて決定されます。
ブラウザレイヤーはアーキテクチャでは変更されていません。ノードの導入により、ブラウザの開発に関する以前の理解を変更したくありません。
ノードの導入は、フロントエンドによって制御されるべきフロントエンド制御部品を引き渡すためだけです。
このモデルでは、開発中の2つのプロジェクトがあります。それらはまだ開始されていませんが、開発効率とパフォーマンスの最適化の観点から、すでに甘さを味わっています。
5。他に何をする必要がありますか？
ノードの開発プロセスをTaobaoの既存のSCMプロセスに統合します。
セッション、ロガー、その他の一般的なモジュールなどのインフラストラクチャ構造。
最良の開発慣行
オンラインのサクセスストーリー
ノードのフロントエンドとバックエンドの分離の概念を誰もが理解しています
安全性
パフォーマンス
…
イノベーションと研究を必要とするテクノロジーはあまり多くありません。また、既製の蓄積がたくさんありました。実際、重要なのは、いくつかのプロセスの開放と一般的なソリューションの蓄積です。より多くのプロジェクトの慣行により、この領域は徐々に安定したプロセスになると信じています。
6。「ミッドウェイアイランド」
「NodeJSに基づくフルスタック開発」モデルはエキサイティングですが、ノードに基づいてフルスタック開発を誰もが受け入れることができるものに変換するためにまだ多くのことがあります。進行中の「ミッドウェイ」プロジェクトは、この問題を解決することです。私たちはそう長くはありませんが、私たちは目標に近づいています！ ！