序文
前面と背面を分離するとき、私が最初に注意を払う問題はレンダリングです。つまり、ビューレベルで機能します。
従来の開発モデルでは、ブラウザとサーバーはフロントエンドとバックエンドの両方の2つのチームによって開発されていますが、テンプレートは2つの間のあいまいな領域にあります。したがって、テンプレートには常にますます複雑なロジックがあり、最終的には維持が困難です。
そして、前面と背面の中間層としてnodejsを選択しました。 nodejsを使用して、ビューレベルで作業をクリアしてみてください。
これにより、フロントエンドとバックエンドの間の分業がより明確になり、プロジェクトがより良く維持され、ユーザーエクスペリエンスが向上します。
この記事
レンダリング作業は、フロントエンド開発者の日常業務の非常に大きな割合であり、バックエンド開発と混同するのが最も簡単な部分でもあります。
過去数年間のフロントエンドテクノロジー開発を振り返ってみると、ビューレベルでの作業は、次のような多くの変更を受けました。
フォームフルページを送信=> ajaxローカルリフレッシュ
サーバー側の継続 + MVC =>クライアント側のレンダリング + MVC
従来のページ変更jump =>単一ページアプリケーション
近年、誰もがこのことをサーバーの端からブラウザの端に移動する傾向があることが観察できます。
サーバー側はサービスに焦点を当て、データインターフェイスを提供します。
ブラウザレンダリングの利点
私たちは皆、ブラウザ側のレンダリングの利点を知っています
1. Javaテンプレートエンジンのビジネスロジックとプレゼンテーションロジックのカップリングと混乱を取り除きます。
2。マルチ末端アプリケーションの場合、インターフェイスが簡単です。ブラウザ側に異なるテンプレートを組み合わせて、さまざまなアプリケーションを提示します。
3。ページレンダリングはHTMLであるだけでなく、フロントエンドでのレンダリングは、コンポーネントの形式（HTML + JS + CSS）の関数を簡単に提供できるため、フロントエンドコンポーネントはサーバーが生成するHTML構造に依存する必要はありません。
4.バックエンドの開発と流通プロセスへの依存を取り除きます。
5.便利なジョイント調整。
ブラウザレンダリングによって引き起こされる短所
しかし、メリットを享受している間、私たちは以下などのブラウザ側のレンダリングの欠点にも直面しています。
1.テンプレートは異なるライブラリで分離されています。サーバー側（Java）に配置されたテンプレートもありますが、他のテンプレートはブラウザ側（JS）に配置されます。フロントとバックエンドのテンプレート言語は接続されていません。
2。レンダリングが開始される前に、すべてのテンプレートとコンポーネントがブラウザにロードされるのを待つ必要があり、すぐに読むことはできません。
3.初めてレンダリングを待っている白い画面がありますが、これはユーザーエクスペリエンスを助長しません
4.単一ページのアプリケーションを開発する場合、フロントエンドルートはサーバー側のルートと一致しません。これは非常に厄介です。
5.すべての重要なコンテンツはフロントエンドで組み立てられていますが、これはSEOを助長しません
フロントエンドとバックエンドの定義を振り返ります
実際、サーバー側（Java）からブラウザ側（JS）にレンダリング作業を行うと、私たちの目的は、フロントエンドとバックエンドの責任を明確に分割することだけであり、ブラウザをレンダリングする必要はありません。
従来の開発モデルでは、サーバーがリリースされ、ブラウザに到達するため、フロントエンドの作業コンテンツはブラウザ側にのみ制限できます。
したがって、多くの人々は、下の写真のように、BackEnd = server frontend = browser側を決定しました。
Taobao Uedが現在進行中のMidway Midwayプロジェクトでは、Javaブラウザの中央にNodejs中間層を構築することにより、ハードウェア環境（サーバーとブラウザー）ではなく、作業責任のためにフロントエンドの分割ラインを再度区別しようとします。
したがって、テンプレートとルートを共有する機会があります。これは、フロントエンドおよびバックエンドの分業で最も理想的な状態でもあります。
途中のタオバオの途中
Midwayプロジェクトでは、ブラウザからフロントエンドとバックエンドをサーバー側に区別するラインを移動しました。
フロントエンドによって簡単に制御され、ブラウザに共通するNodeJSレイヤーを使用すると、フロントエンドの分離をより明確に完了できます。
また、フロントエンド開発がさまざまな状況に最も適したソリューションを決定できるようにすることも可能です。すべてがブラウザ側で処理される代わりに。
責任の分割
Midwayは、フロントエンドがバックエンドのジョブをつかもうとするプロジェクトではありません。目的は、テンプレートのあいまいな領域を明確にカットし、責任のより明確な分割を取得することです。
バックエンド（Java）、焦点を合わせています
1。サービスレイヤー
2。データ形式とデータの安定性
3。ビジネスロジック
フロントエンド、焦点
1.UIレイヤー
2。ロジックを制御し、ロジックをレンダリングします
3。インタラクション、ユーザーエクスペリエンス
サーバー側またはブラウザ側の違いに固執しなくなりました。
テンプレート共有
従来の開発モデルでは、ブラウザとサーバーはフロントエンドとバックエンドの両方の2つのチームによって開発されていますが、テンプレートは2つの間のあいまいな領域にあります。したがって、テンプレートには常にますます複雑なロジックがあり、最終的には維持が困難です。
nodejsを使用すると、バックエンドの学生は、Java層のビジネスロジックとデータの開発に集中できます。フロントエンドの学生は、制御ロジックとレンダリングの開発に焦点を当てています。また、これらのテンプレートを選択して、サーバー側（nodejs）またはブラウザ側をレンダリングすることができます。
同じテンプレート言語xtemplateと同じレンダリングエンジンJavaScriptを使用
同じ結果が異なるレンダリング環境（サーバー側、PCブラウザー、モバイルブラウザー、Webビューなど）でレンダリングされます。
ルーティング共有
また、nodejsレイヤーのため、ルーティングをより慎重に制御できます。
フロントエンドでブラウザ側のルーティングを実行する必要がある場合は、ブラウザー側のページまたはサーバー側のページを変更できるように、サーバー側のルーティングを同時に構成でき、一貫したレンダリング効果を得ることができます。
同時に、SEOの問題も処理されました。
テンプレート共有の実践
通常、ブラウザでテンプレートをレンダリングするとき、プロセスは
ブラウザにテンプレートエンジンを入力します（Xtmpleate、Juicer、Handlerbarなど）
ブラウザ側にテンプレートアーカイブをロードすると、この方法は
<script type = "js/tpl"> ... </script>を使用してページに印刷します
モジュールロードツールを使用して、テンプレートアーカイブ（KISSY、requireJSなど）をロードします。
他の
データを取得し、テンプレートエンジンを使用してHTMLを生成します
指定された場所にHTMLを挿入します。
上記のプロセスは、テンプレートのクロスエンド共有を実現したい場合、実際には一貫したモジュール選択に焦点が当てられていることがわかります。
KMD、AMD、CommonJSなど、市場には多くの一般的なモジュール標準があります。 nodeJSテンプレートアーカイブが一貫したモジュール仕様を介してnodeJSエンドに出力できる限り、基本的なテンプレート共有を実行できます。
その後の一連の記事では、モデルのプロキシと共有についてさらに説明します。
ケースディスカッション
ミッドウェイアイランドの中間層のため、過去の質問に対するより良い答えがあります。
ケース1複雑なインタラクティブアプリケーション（ショッピングカート、注文ページなど）
ステータス：すべてのHTMLはフロントエンドでレンダリングされ、サーバーはインターフェイスのみを提供します。
問題：ページに入ると、短い白い画面があります。
答え：
ページを初めて入力し、nodejs側のページ全体をレンダリングし、バックグラウンドで関連テンプレートをダウンロードします。
その後のインタラクション、ブラウザ側の部分的な更新を完全に更新します
同じテンプレートを使用すると同じ結果が生成されます
ケース2シングルページアプリケーション
ステータス：クライアントサイドMVCフレームワークを使用して、ブラウザ内のページを変更します。
問題：レンダリングとページの交換は両方ともブラウザ側で完了します。 F5にURLを直接入力または更新すると、同じコンテンツを直接表示することはできません。
答え：
ブラウザ側とnodejs側で同じルート設定を共有する
ブラウザ側のページを変更するときは、ルートを変更し、ブラウザ側のページコンテンツをレンダリングします。
同じURLを直接入力するときは、NodeJS側でページフレーム +ページコンテンツレンダリングを使用します
ブラウザのページを変更する場合でも、同じURLを直接入力する場合でも、表示されるコンテンツは同じです。
経験の増加と論理的な複雑さを減らすことに加えて。また、SEOの問題も解決しました
ケース3の純粋なブラウジングページ
ステータス：ページは、情報のみを提供します。
問題：HTMLはサーバー側で生成され、CSSとJSは別の場所に配置され、互いに依存関係があります。
答え：
nodejsを通じて、html + css + jsの統一された管理
将来複雑なアプリケーションまたは単一ページアプリケーションに拡張する必要がある場合は、簡単に転送することもできます。
ケース4クロスターミナルページ
ステータス：同じアプリケーションが異なるエンドポイントで異なるインターフェイスと相互作用を提示する必要があります
問題：HTML管理は簡単ではなく、さまざまなHTMLがサーバー側で生成されることが多く、ブラウザ側で異なる処理が行われます。
答え：
クロスターミナルページは問題のレンダリングであり、フロントエンドで処理されます。
NodeJSレイヤーおよびバックエンドサービスを通じて、このタイプの複雑なアプリケーション向けに最適なソリューションを設計できます。
要約します
Ajax、クライアント側MVC、SPA、過去の双方向データ結合などの技術の出現はすべて、当時のフロントエンド開発で遭遇したボトルネックを解決しようとする試みでした。
NodeJS中間層の出現は、フロントエンドが現在ブラウザに限定されているという制限を解決する試みでもあります。
この記事では、フロントエンドとバックエンドのテンプレートの共有に焦点を当てており、注目を集めたいと考えています。ワークフローを改善し、バックエンドと協力して、Nodejs中間レイヤーアーキテクチャの下でフロントエンドでより良い仕事をする方法について説明しましょう。