NodeJSによるフロントエンドとバックエンドの分離の考え方と実践(2) テンプレートexploration

はしがき

フロントエンドとバックエンドを分離する場合、最初に注目するのはレンダリング、つまりビューレベルでの作業です。

従来の開発モデルでは、ブラウザ側とサーバー側は異なるフロントエンドチームとバックエンドチームによって開発されますが、テンプレートは 2 つの間のあいまいな領域にあります。したがって、ますます複雑なロジックがテンプレートに追加されることは避けられず、最終的には保守が困難になります。

そして、フロントエンドとバックエンドの間の中間層として NodeJS を選択しました。 NodeJS を使用してビューレベルでの作業を効率化しようとしています。

フロントエンドとバックエンドの間の役割分担がより明確になり、プロジェクトをより適切に維持できるようになり、より良いユーザーエクスペリエンスを実現できます。

この記事

レンダリングは、フロントエンド開発者の日常作業の非常に大きな部分を占めており、バックエンド開発と絡み合う可能性が最も高い領域でもあります。

過去数年間のフロントエンドテクノロジーの開発を振り返ると、ビューレベルの作業は次のような多くの変化を遂げてきました。

フォーム送信でページ全体を更新 => AJAX 部分更新
サーバー側のレンダリング MVC => クライアント側のレンダリング MVC
従来のページ変更ジャンプ => 単一ページアプリケーション
過去数年間、誰もがレンダリングをサーバー側からブラウザ側に移行する傾向にあることがわかります。

サーバー側はサービス化に重点を置き、データインターフェイスを提供します。

ブラウザ側レンダリングの利点

などのブラウザ側レンダリングの利点は誰もが知っています。

1. Java テンプレートエンジンにおけるビジネスロジックとプレゼンテーションロジックの結合と混乱を取り除きます。
2. 複数端末アプリケーションの場合、インターフェイスが簡単になります。ブラウザ側で異なるテンプレートを使用して、異なるアプリケーションを表示します。
3. ページレンダリングは HTML だけではありません。フロントエンドレンダリングは、コンポーネント化された形式 (html js css) で機能をより簡単に提供できるため、フロントエンドコンポーネントはサーバーによって生成された HTML 構造に依存する必要がありません。
4. バックエンドの開発およびリリースプロセスへの依存を排除します。
5. 共同デバッグを容易にします。

ブラウザ側のレンダリングによるデメリット

しかし、利点を享受する一方で、ブラウザ側のレンダリングによってもたらされる次のような欠点にも直面します。

1. テンプレートは複数のライブラリに分かれています。テンプレートの中にはサーバー側 (JAVA) に配置されるものと、ブラウザー側 (JS) に配置されるものがあります。フロントエンドとバックエンドのテンプレート言語は接続されていません。
2. レンダリングを開始するには、すべてのテンプレートとコンポーネントがブラウザにロードされるまで待つ必要があり、すぐに表示することはできません。
3. 初めて入力すると、レンダリング時間を待つ白い画面が表示されます。これはユーザーエクスペリエンスに役立ちません
4. シングルページアプリケーションを開発する場合、フロントエンドのRouteとサーバーサイドのRouteが一致しないため、対処が非常に面倒です。
5. 重要なコンテンツがフロントエンドで組み立てられているため、SEO に貢献しません

フロントエンドとバックエンドの定義を振り返る

実際、振り返ってみると、レンダリング作業をサーバー側 (Java) からブラウザ側 (JS) に移行したときの目的は、フロントエンドとバックエンドの責任を明確に分割することだけでした。ブラウザのレンダリングが不可欠だったという意味ではありません。

ただ、従来の開発モデルではサーバーを出た後ブラウザに行くため、フロントエンドの作業内容はブラウザ側に限定できます。

このため、下の図のように、バックエンド = サーバー側、フロントエンド = ブラウザ側と信じている人が多いです。

淘宝UEDが現在進めているMidwayプロジェクトでは、JAVAとブラウザの間にNodeJS中間層を構築することで、ハードウェア環境ではなく作業責任に基づいてフロントエンドとバックエンドの境界線を再定義しようとしています。 (サーバーとブラウザ) を区別するため。

したがって、テンプレートとルートを共有する機会が得られます。これは、フロントエンドとバックエンドの分業における最も理想的な状態でもあります。

タオバオミッドウェイミッドウェイ

Midway プロジェクトでは、フロントエンドとバックエンドを区切る線をブラウザ側からサーバー側に戻しました。

フロントエンドによって簡単に制御され、ブラウザーと共通の Nodejs レイヤーを使用すると、フロントエンドとバックエンドの分離をより明確に完了できます。

フロントエンド開発者にさまざまな状況に最適なソリューションを決定させることもできます。すべてがブラウザ側で処理されるのではなく。

責任分担

Midway は、バックエンドの仕事を奪おうとするフロントエンドプロジェクトではありません。その目的は、テンプレートのあいまいな領域を排除し、より明確な責任分担を取得することだけです。

バックエンド (JAVA)、
に重点を置く 1.サービス層
2. データ形式とデータの安定性
3.ビジネスロジック

フロントエンド、
に焦点を当てる 1.UIレイヤー
2. 制御ロジックとレンダリングロジック
3. インタラクションとユーザーエクスペリエンス

サーバー側とブラウザ側の違いにこだわる必要はもうありません。

テンプレートの共有

NodeJS を使用すると、バックエンドの学生は JAVA 層でのビジネスロジックとデータの開発に集中できます。フロントエンドの学生は、制御ロジックの開発とレンダリングに焦点を当てます。また、これらのテンプレートをサーバー側 (NodeJS) でレンダリングするかブラウザー側でレンダリングするかを選択できます。

同じテンプレート言語 XTemplate と同じレンダリングエンジン JavaScript を使用します

異なるレンダリング環境 (サーバーサイド、PC ブラウザ、モバイルブラウザ、Web ビューなど) で同じ結果をレンダリングします。

ルート共有

NodeJS レイヤーにより、より詳細にルーティングを制御できます。

フロントエンドでブラウザ側のルーティングを実行する必要がある場合は、サーバー側のルーティングを同時に構成して、ブラウザ側のページ変更またはサーバー側のページ変更中に一貫したレンダリング効果を得ることができます。

同時に、SEO の問題にも対処しました。

テンプレート共有の実践

通常、ブラウザ側でテンプレートをレンダリングするときのプロセスは

にすぎません。

ブラウザにテンプレートエンジン (xtmpleate、ジューサー、ハンドラーバーなど) をロードします
ブラウザにテンプレートファイルをロードします。メソッドは
です。ページに印刷するにはを使用します。モジュール読み込みツールを使用してテンプレートファイル (KISSY、requireJS など) を読み込みます
その他
データを取得し、テンプレートエンジンを使用して HTML を生成します
指定した場所に html を挿入します。
上記のプロセスから、テンプレートのクロスエンド共有を実現するために、実際には一貫したモジュールの選択に重点が置かれていることがわかります。

市場には、KMD、AMD、CommonJS などの一般的なモジュール標準が多数あり、NodeJS テンプレートファイルを一貫したモジュール仕様で NodeJS 側に出力できれば、基本的なテンプレートの共有が可能です。

後続の一連の記事では、モデルのプロキシと共有についてさらに詳しく説明します。

ケーススタディ

ミッドウェー島の中層のため、

など、過去のいくつかの問題はより良く解決されています。

ケース 1 複雑な対話型アプリケーション (ショッピングカート、注文ページなど)

ステータス: すべての HTML はフロントエンドでレンダリングされ、サーバーはインターフェイスのみを提供します。

問題: ページに入るときに、短い白い画面が表示されます。
答え:
初めてページに入ると、NodeJS 側でフルページのレンダリングが実行され、関連するテンプレートがバックグラウンドでダウンロードされます。
後続の対話型操作はブラウザ側で部分更新により完了します
同じテンプレートを使用すると同じ結果が得られます

ケース 2 シングルページアプリケーション

ステータス: クライアント側 MVC フレームワークを使用して、ブラウザー内のページを変更します。

問題点：ブラウザ側でレンダリングやページ遷移が完了しますが、URLを直接入力した場合やf5で更新した場合、同じ内容を直接表示することができません。
答え:
ブラウザ側とNodeJS側で同じRoute設定を共有します
ブラウザ側でページを変更する場合、ブラウザ側でルートの変更とページコンテンツのレンダリングを実行します
同じURLを直接入力すると、ページフレームとページコンテンツがNodeJS側で描画されます
ブラウザ側でページを切り替えても、同じURLを直接入力しても、表示される内容は同じです。
エクスペリエンスが向上し、ロジックの複雑さが軽減されるだけでなく。 SEO の問題も解決します

ケース 3 純粋な閲覧ページ

ステータス: このページは情報のみを提供し、インタラクションはほとんどまたはまったくありません

問題: HTML はサーバー側で生成され、CSS と JS は別の場所に配置され、相互に依存します。
答え:
NodeJSを通じて、html css jsを一元管理
将来、複雑なアプリケーションや単一ページのアプリケーションに拡張する必要がある場合でも、簡単に移行できます。

ケース 4 クロスターミナルページ

状況: 同じアプリケーションが、異なるエンドポイントで異なるインターフェイスと対話を提供する必要があります

問題: HTML の管理が容易ではない。サーバー側で別の HTML が生成されることが多く、ブラウザ側でも別の処理が必要になる
答え:
クロスターミナルページはレンダリングの問題であり、フロントエンドによって均一に処理されます。
NodeJS レイヤーとバックエンドのサービス化を通じて、この種の複雑なアプリケーションに最適なソリューションを設計できます。

概要

AJAX、クライアントサイド MVC、SPA、双方向データバインディング、および過去のその他のテクノロジの出現はすべて、当時のフロントエンド開発で遭遇したボトルネックを解決するための試みでした。

NodeJS 中間層の登場は、現在のフロントエンドがブラウザ側に限定されているという制限を解決する試みでもあります。

この記事はフロントエンドとバックエンドのテンプレート共有に焦点を当てており、他の人がワークフローを改善する方法や、NodeJS 中間層アーキテクチャの下でバックエンドと連携する方法について議論するきっかけになれば幸いです。 -end はより良い仕事をします。