NodeJSによるフロントエンド・バックエンド分離の思考と実践(1) フルスタック開発_node.js

はじめに

従来の Web 開発モデルによって引き起こされるさまざまな問題を解決するために、私たちは多くの試みを行ってきましたが、フロントエンドとバックエンドの間に物理的なギャップがあるため、試した解決策はどれも似通ったものになってしまいました。その苦い経験から学び、今日は「フロントエンドとバックエンド」の定義を再考し、フロントエンド学生にとって馴染みのあるNodeJSを導入し、新しいフロントエンドとバックエンドの分離モデルを模索してみます。 。

さまざまな端末 (パッド/モバイル/PC) の台頭により、開発者に対する要件はますます高くなっており、純粋なブラウザー側の応答性では、さまざまなユーザー エクスペリエンスに対する高い要件を満たすことができなくなりました。カスタマイズされたバージョン。開発効率を向上させるために、バックエンドがビジネス/データインターフェースを担当し、フロントエンドが表示/インターフェースを担当するフロントエンドとバックエンドの分離の必要性がますます高まっています。インタラクション ロジックをカスタマイズして、同じデータ インターフェイスの複数のバージョンを開発できます。

このトピックは最近よく議論されており、アリババの一部の BU もいくつかの試みを行っています。長い議論の結果、私たちのチームは NodeJS に基づいたフロントエンドとバックエンドの分離ソリューションを検討することにしました。その過程で、いくつかの理解と考えが変わりました。これをクラスメートにも見ていただけると幸いです。ディスカッションに参加し、改善に協力してください。

1. フロントエンドとバックエンドの分離とは何ですか?

グループでの最初のディスカッション中に、フロントエンドとバックエンドの分離について全員が異なる理解を持っていることがわかりました。同じチャネルで議論できるようにするには、まず次の点に到達する必要があります。 「フロントエンドとバックエンドの分離」とは何かについての合意。

誰もが同意するフロントエンドとバックエンドの分離の例は、SPA (シングルページ アプリケーション) であり、使用されるすべての表示データは、非同期インターフェイス (AJAX/JSONP) を介してバックエンドによって提供されます。フロントエンドはそれを表示するだけです。
ある意味では、SPA はフロントエンドとバックエンドの分離を実現しますが、このアプローチには 2 つの問題があります。

WEBサービスの中でSPAが占める割合は小さい。多くのシナリオでは、同期/同期モードと非同期モードが混在しており、SPA を万能のソリューションとして使用することはできません。
現在の SPA 開発モデルでは、通常、インターフェイスはプレゼンテーション ロジックに基づいて提供されます。効率を向上させるために、バックエンドが一部のプレゼンテーション ロジックの処理を支援することがあります。これは、バックエンドが依然としてビュー層の作業に関与していることを意味します。フロントエンドとリアエンドの分離は現実的ではありません。
SPA スタイルのフロントエンドとバックエンドの分離は、物理層に基づいています (クライアントである限り、それがフロントエンドであり、サーバー側がバックエンドであると考えられています)。この分割方法では、フロント エンドとバック エンドを分離するというニーズを満たすことはできなくなりました。現在の使用シナリオを満たすことができると考えています。

フロントエンド: ビュー層とコントローラー層を担当します。
バックエンド: モデル層、ビジネス処理/データなどのみを担当します。
この役割分担の理由については後で説明します。

2. なぜフロントエンドとバックエンドを分離する必要があるのですか?

この問題については、Yu Bo の記事「Web R&D モデルの進化」で非常に包括的に説明されています。簡単に概要を説明します。

2.1 既存の開発モデルの適用可能なシナリオ

Yu おじさんが言及したいくつかの開発モデルには、それぞれ適用可能な独自のシナリオがあり、他のモデルを完全に置き換えることはできません。

たとえば、バックエンドに重点を置いた MVC は、一部の同期表示ビジネスを行う場合には非常に効率的ですが、同期と非同期を組み合わせたページとなると、バックエンド開発との通信がより面倒になります。
Ajax は主要な SPA 開発モデルであり、APP 開発シナリオにより適していますが、SEO などの問題を解決するのが難しいため、この開発方法は多くの種類のシステムにとって負荷が高すぎるため、APP にのみ適しています。
2.2 フロントエンドとバックエンドの不明確な責任

複雑なビジネス ロジックを備えたシステムでは、フロントエンドとバックエンドが混在するコードを維持することが最も懸念されます。制約がないため、時間の経過とともに、M-V-C の各層に他の層のコードが含まれる可能性があります。メンテナンス性が全くありません。
フロントエンドとバックエンドの分離によってこの問題が完全に解決されるわけではありませんが、大幅に軽減することは可能です。それができないことが物理的に保証されているからです。

2.3 開発効率の問題

タオバオの Web は基本的に MVC フレームワーク webx に基づいており、フロントエンドがバックエンドのみに依存できることがアーキテクチャによって決定されます。
したがって、私たちの開発モデルは依然として、フロントエンドで静的デモを作成し、それをバックエンドで VM テンプレートに変換するというモデルです。このモデルの問題については、長い間批判されてきましたが、ここでは触れません。
バックエンド環境を基に直接開発するのも大変ですし、設定、インストール、使用も面倒です。この問題を解決するために、VMarket などのさまざまなツールを発明しましたが、フロントエンドは依然として VM を記述する必要があり、バックエンドのデータに依存しているため、効率はまだ高くありません。
さらに、バックエンドはプレゼンテーションへの強いこだわりを捨てて、ビジネス ロジック層の開発に集中することができません。

2.4 フロントエンドのパフォーマンスの制限

パフォーマンスの最適化がフロントエンドのみで行われる場合、スペースは非常に限られているため、スパークを実現するにはバックエンドの協力が必要になることがよくありますが、バックエンドのフレームワークの制限により、それは困難です。 Comet や Bigpipe などの技術ソリューションを使用してパフォーマンスを最適化します。

上記の問題のいくつかを解決するために、私たちは多くの試みを行い、さまざまなツールを開発してきましたが、主にバックエンド プレイに割り当てられた小さなスペースしか使用できないため、大きな改善はありませんでした。フロントエンドとバックエンドを真に分離することによってのみ、上記の問題を完全に解決することができます。

3. フロントエンドとバックエンドを分離するにはどうすればよいですか?

フロントエンドとバックエンドを分離するにはどうすればよいでしょうか?実際、答えは最初のセクションにあります:

フロントエンド: ビュー層とコントローラー層を担当します。
バックエンド: モデル層、ビジネス処理/データなどを担当します。

想像してみてください。フロントエンドがコントローラーをマスターすれば、シーンに応じてサーバー側で同期的にレンダリングするかどうかを決定したり、ビューレイヤーのデータに基づいて JSON データを出力したりすることも簡単に行うことができます。 、Comet など、プレゼンテーション層のニーズに基づいて、その使用方法を決定するのは完全に需要に基づいています。

3.1 NodeJS に基づく「フルスタック」開発

上の図の階層化を実現したい場合は、フロントエンドとバックエンドで行うことの実現を支援する Web サービスが必ず必要になるため、前述の「NodeJS に基づくフルスタック開発」があります。タイトルにある

この図はシンプルでわかりやすく見えますが、試したことがない場合は、多くの疑問が生じるでしょう。

SPA モードでは、バックエンドは必要なデータ インターフェイスをすでに提供しており、ビュー フロントエンドはすでに制御できます。なぜ NodeJS の追加レイヤーを追加するのでしょうか?
もう 1 つのレイヤーを追加した場合のパフォーマンスはどうですか?
レイヤーをもう 1 つ追加すると、フロントエンドの負荷は増加しますか?
レイヤーを追加するとリスクも増加します。
NodeJS は何でもできるのに、なぜ JAVA が必要なのでしょうか?
これらの問題を明確に説明するのは簡単ではありません。以下に私の理解プロセスについて話しましょう。

3.2 NodeJS のレイヤーを追加する理由は何ですか?

現段階では、主にバックエンド MVC モデルで開発を行っていますが、このモデルはフロントエンド開発の効率を大きく妨げ、バックエンドがビジネス開発に集中できなくなります。
解決策は、フロントエンドがコントローラー層を制御できるようにすることですが、すべてのフロントエンドが Java を学習し、バックエンド開発環境をインストールし、 VM を書き込みます。
NodeJS はこの問題をうまく解決できます。新しい言語を学ぶ必要はなく、以前の開発者がやってくれたことをそのまま実行できるので、すべてがとても自然に思えます。

3.3 パフォーマンスの問題

階層化には各層間の通信が含まれるため、一定のパフォーマンスの低下が確実に発生します。ただし、合理的な階層化により責任が明確になり、コラボレーションが容易になり、開発効率が大幅に向上します。階層化によって生じる損失は、他の分野での利益によって間違いなく補われるでしょう。
また、階層化を決めたら、通信方式やプロトコルを最適化することで損失を最小限に抑えることができます。

例:
Taobao Baby の詳細ページが静的になった後も、物流、プロモーションなど、リアルタイムで取得する必要がある情報がまだたくさんあります。この情報は異なるビジネス システムにあるため、フロントエンドは 5 つのデータを送信する必要があります。または、コンテンツを入力するための 6 つの非同期リクエスト。
NodeJS を使用すると、フロントエンドは NodeJS でこれら 5 つの非同期リクエストをプロキシでき、この最適化により全体的なレンダリング効率が大幅に向上します。
PC では 5 つまたは 6 つの非同期リクエストを送信しても問題ないと思われるかもしれませんが、ワイヤレス側では、クライアントの携帯電話で HTTP リクエストを確立するのに非常にコストがかかります。この最適化により、パフォーマンスが数倍向上します。

淘宝網の詳細: 現在、NodeJS に基づいて淘宝網を最適化しています。オンラインになった後の最適化プロセスを共有します。

3.4 フロントエンドのワークロードは増加しましたか?

単にページを切り取ったり、デモを実行したりすることに比べれば、確かに多少の追加はありますが、現在のモデルでは、共同デバッグと通信リンクが存在します。このプロセスは非常に時間がかかり、バグが発生しやすく、保守が困難です。
そのため、作業量は若干増えますが、全体的な開発効率は大幅に向上します。

さらに、テストコストも大幅に節約できます。以前に開発されたインターフェイスはすべてプレゼンテーション層用であったため、テスト ケースを作成するのが困難でした。フロントエンドとバックエンドが分離されている場合、テストさえも分離することができ、あるグループの人はインターフェイスのテストに集中し、別のグループの人は UI のテストに集中することになります (この部分の作業を置き換えることもできます)。ツールによる）。

3.5 ノード層の追加によってもたらされるリスクをどのように制御するか?

Node の大規模な使用に伴い、システム/運用保守/セキュリティ部門の学生がインフラストラクチャの構築に確実に参加し、各リンクで発生する可能性のある問題を改善し、システムの安定性を確保します。

3.6 Node は何でもできるのに、なぜ JAVA が必要なのでしょうか?

私たちの本来の目的は、フロントエンドとバックエンドを分離することです。この問題を考慮すると、本来の目的に反します。 Java の代わりに Node を使用したとしても、責任の所在が不明瞭になるなど、現在直面しているさまざまな問題が起こらないという保証はありません。私たちの目標は、プロフェッショナルな人々がプロフェッショナルな仕事に集中して、階層的に開発することです。 JAVA ベースのインフラストラクチャはすでに非常に強力で安定しており、現在のアーキテクチャを実行するのにより適しています。

4. ノードに基づく淘宝網のフロントエンドとバックエンドの分離

上の図は、ノードに基づくタオバオのフロントエンドとバックエンドの分離と階層化、およびノー​​ドの責任範囲についての私の理解です。簡単な説明:

トップエンドはサーバーであり、私たちがよくバックエンドと呼ぶものです。私たちにとって、バックエンドはインターフェイスの集合であり、サーバーは使用するためのさまざまなインターフェイスを提供します。 Node層があるため、サービスの形態を制限する必要がありません。バックエンド開発では、ビジネス コードを考慮するインターフェイス実装のみを使用します。
サーバーの下には Node アプリケーションがあります。
Node アプリケーションには、サーバーと通信するためのモデル プロキシの層があります。この層は現在、さまざまなインターフェイスを呼び出す方法をスムーズにし、ビュー層に必要ないくつかのモデルをカプセル化することを主な目的としています。
ノード層は、オリジナルの vmcommon、tms (淘宝網コンテンツ管理システムを指す)、およびその他の要件も簡単に実現できます。
ノード層にどのフレームワークを使用するかを決定するのは開発者です。ただし、フロントエンドとバックエンドで共有できる xTemplate を組み合わせて使用​​することをお勧めします。
Node の使用方法は誰もが決定しますが、興味深いのは、最終的に Node を使用して、必要な出力メソッド (JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同期、非同期など) を簡単に実現できることです。調整するかどうかはシーンによって異なります。
私たちのアーキテクチャではブラウザー層は変わっていません。Node の導入によってブラウザーでの開発に対するこれまでの理解が変わることは望ましくありません。
Nodeの導入は、フロントエンドが制御すべき部分をフロントエンド制御するだけです。
このモデルはまだ発売されていませんが、すでに 2 つのプロジェクトが開発中です。開発効率とパフォーマンスの最適化の点で、すでにメリットを実感しています。

5. 他に何をする必要がありますか?

Node の開発プロセスをタオバオの既存の SCM プロセスに統合します。
セッション、ロガー、その他の共通モジュールなどのインフラストラクチャの構築。
開発のベストプラクティス
オンラインの成功事例
Node
におけるフロントエンドとバックエンドの分離の概念に対する全員の理解 安全です
パフォーマンス
…
技術的に革新したり研究したりする必要があるものはあまりなく、既製の蓄積がすでにたくさんあります。実際、重要なのは、いくつかのプロセスを明確にし、共通の解決策を蓄積することです。これは、プロジェクトの実践を重ねることで、徐々に安定したプロセスになると思います。

6.「ミッドウェイ」

「NodeJS に基づくフルスタック開発」モデルは非常にエキサイティングですが、Node に基づくフルスタック開発を安定した、誰もが受け入れられるものに変えるにはまだ長い道のりがあり、現在取り組んでいます。 「ミッドウェイ」プロジェクトは、この問題を解決するために設計されました。まだまだ始まったばかりですが、着実に目標に近づいています！ ！