フロントエンドとバックエンドの分離ソリューション_html/css_WEB-ITnose

0.悟空

悟空は、「ドラゴンボール」の主人公、孫悟空です。彼は優れた超能力を持っており、世界の問題を解決することができます。同様に、フロントエンドとバックエンドを分離しようとすることで、フロントエンド開発における現在の問題点を解決することも期待されています。

1. 基本的な考え方

全体として MVC アーキテクチャを使用すると、Angular (双方向バインディング) とは異なり、一方向のデータ フローには次の利点があります。予測可能性、ビュー層の変更はモデルから来る必要があります

パフォーマンスの向上
• MVC の各層で使用される基本テクノロジー:

view: ビュー層のレンダリングとして React を使用し、ここでのレンダリングはノードに分割されます側、ブラウザ側のReact の仮想 DOM、UI への重点、および一方向フローは、ページのパフォーマンスを解決するための強力なツールです。

コントローラー: 反応ルーターは歴史に基づいて構築されており、単一ページのアプリケーションを実装し、ルーティング管理を実行するために使用されます。 React-router を使用すると、リクエストの分散を簡単に処理できます。
モデル: Redux はデータの流れを実現するために使用され、immutable.js は状態の不変性を解決し、参照によって引き起こされる副作用を回避するために使用されます。
• 2. 全体的なアーキテクチャ

悟空の全体的なアーキテクチャは、主にブラウザ、nginx、ノード中間層、バックエンド サーバーの 4 つのエンティティで構成されます。従来の Web サイトのアーキテクチャと比較して、追加のノード中間層があり、これも悟空のコアです。

3. 詳細な説明

3.1 ブラウザ

react-router が使用されるため、システム全体が単一ページ アプリケーション (SPA) になります:

ページが初期化されると、最初の画面データがレンダリングされて表示されます。

セカンド スクリーン データは ajax を介して非同期的に取得され、ブラウザ側でレンダリングされる必要があります
• ここで問題があります: フロントエンドとバックエンドのレンダリングの一貫性が確保されているかどうかです。前後の結果の一貫性を維持するには、react の data-react-checksum が必要です。

最初の画面データは、JSON.stringify(datat) を通じてページに渡す必要があります

動的コンテンツの生成を避けてください。たとえば、new Date() がある場合、ノードとブラウザのレンダリング後の時間は異なります
• 3.2 nginx

nginx は非常に人気があり、リクエストの分散と負荷分散に役割を果たしています。ここでは、さまざまなリクエストが nginx を通じてさまざまなサーバーに分散されます。

url リクエストはノード サーバーに均一に分散され、そこからフロントエンドの静的リソースが取得されます。

api リクエストはバックエンド サービスに直接送信されます。もちろん、ノード サーバーを使用して転送することもできます
• 3.3 ノード サーバー

ノード サーバーは 2 つの役割を果たす中間層です:

フロントエンドの静的リソースの管理

最初の画面データのレンダリング
• 具体的には、以下の機能点に分けることができます:

3.3.1 ルートマッチング

アイデア: リクエストされた URL + React Router のルーター設定情報に従って、一致するコンポーネントを取得します

import { match, RoutingContext } from 'react-router';import routes from './routes';serve((req, res) => {  match({ routes, location: req.url }, (err, rediction, renderProps) => {    if (...) {      res.status(200).send(htmlStr);    }  })})

3.3.2 最初のコンポーネントを取得します画面データ

アイデア: 各 URL はすべて指定されたファースト スクリーン データを持ち、すべてのデータが取得されると、コールバック関数が実行されます

Promise.all([promise1, promise2, ..., promisen], (vals)=> {  ...  const initialState = val;  const store = createStore(reducer, initialState);})

3.3.3 静的レンダリング

アイデア:静的データを取得するには、react の renderToString を使用します

Promise.all([promise1, promise2, ..., promisen], (vals)=> {  ...  const initialState = val;  const store = createStore(reducer, initialState);  ...  const props = { store, ... };  str = React.renderToString(App, props);});

3.3.4 データ モック

アイデア: 各 API は対応する js ファイルに対応し、js ファイルは、mockjs データ テンプレートを通じてデータ モックを完成させます

3.3.5 完全な HTML に戻る

アイデア: Get 3.3 文字列 str は、HTML の他のコンテンツ (mta、3f1c4e4b6b16bbbd69b2ee476dc4f83a など) および最初の画面データ (initialState) と結合されて、完全な HTML 文字列を取得します

3.4 ブラウザ化パッケージの構築

By browserifyのtransform機能とプラグインを使う 機能の拡張により、できることはさらに増えます。また、watchify を使用してファイルの変更を監視します。

3.4.1 require css file

アイデア: cssモジュールを使用してcssファイルをjsオブジェクトとcssオンラインファイルにマッピングし、jsxで直接cssを要求します

3.4.2 コード分割

アイデア:すべてのファイルを js ファイルにパックすることは避け、browserify のプラグイン メカニズム (factor-bundle プラグインを使用) を使用して js ファイルを分割し、その後、react router の getComponent と getChildroutes を使用して動的読み込みを完了します。

3.4.3 モジュールのパッケージ化

3.4.2 を通じて、ファイルはパブリック js ファイルといくつかのビジネス ファイルにパッケージ化され、ツリー構造を使用してファイルが整理されます。同様: https://github.com/rackt/react-router/tree/master/examples/huge-apps

3.5 監視システム

ノードサービスの安定性を確保するには、何らかの監視が必要です。サービスの安定性: ノード管理、ファルコンマシン監視、ブラウザ例外の監視収集、パフォーマンス監視、権限管理、ログ管理などの機能

3.6 ノードはバックエンドサービスと通信します

現在イントラネットドメイン名を通じてアクセスされています、もちろんこれです この方法にはいくつかの問題があります: もう 1 つのドメイン名解決、アクセス プロトコルなどです。

3.7 バックエンド サービス

このアーキテクチャでは、バックエンド サービスは API のみを提供し、バックエンド テンプレートと URL コントローラーは関与しなくなり、バックエンドの学生はデータ処理に集中でき、ページの表示に注意を払う必要がなくなります。フロントエンドとバックエンドがより明確になります。

4. 最近の考え

4.1 フロントエンドとバックエンドの分離のコストと利点

まず最も大きな利点について話しましょう:

スピード: フロントエンド開発はバックエンド サービスに依存しなくなり、バックエンド データにより、開発速度が向上します
責任: フロント エンドとバック エンドの分業がより明確になり、フロント エンドはデータの表示と対話型処理に重点を置き、バック エンドはデータ処理とデータ ストレージに重点を置きます。

コスト:

複雑さ: 追加の中間層があり、アーキテクチャ全体がより複雑になります
メンテナンス: ノードの安定性と信頼性を確保するために、ノードサービスのメンテナンス
競合: 開発の初期段階では、バックエンドはページをまったく表示できず、患者への説明が必要です
パフォーマンス: 最初の画面をレンダリングするときに、ノードサービスは次のことを行う必要があります。バックエンド サービスにアクセスすると、間違いなくパフォーマンスが低下します

上記の問題を考慮すると、個人的には、現在のフロントエンドとバックエンドの分離は、アクセス数が少ない一部の内部システムに適していると思います。ただし、大規模な PV ページでは依然として従来の 2 層アーキテクチャ (B/S) が使用されます。

4.2 フロントエンド エンジニアの開発の方向性

Web アプリケーション: クラウド コンピューティングの発展により、ますます多くのアプリケーションがネットワーク化されるため (現在の起業家の Red Sea Sass アプリケーションなど)、フロントエンド エンジニアは次のことを行う必要があります。ますます複雑になるビジネス シナリオ
データの視覚化: これはビッグ データと大きく関係しています
モバイル: モバイル インターネット時代が到来し、H5 がますます増えています。多くの企業の戦略はモバイルファーストです
フルエンド: Andriod、IOS、FE はすべてクライアント上で動作し、React Native の出現により、3 つは統合の傾向にあります
フルスタック: 現在。フロントエンドとバックエンドの分業にはメリットもありますが、不必要なコミュニケーションが多く発生し、Web サイト全体の開発を人為的に分割してフルスタック開発に戻すこともトレンドです

。