序文
近年、さまざまなサイトのWebベースのマルチターミナル適応が本格的に行われており、さまざまな技術に依存しているソリューションも業界の間で開発されています。ブラウザのネイティブCSS3メディアクエリに基づいたレスポンシブデザイン、クラウドインテリジェントな再配置などに基づく「クラウド適応」ソリューションなど。この記事では、主にフロントエンドとバックエンドの分離に基づくマルチ末端適応ソリューションについて説明します。
フロントエンド分離について
フロントエンド分離の解決策に関して、「nodejs（i）に基づくフロントエンド分離の思考と実践」には非常に明確な説明があります。 Serverインターフェイスとブラウザの間のレンダリングレイヤーとしてnodejsを導入しました。 NodeJSレイヤーはデータから完全に分離されており、多くのビジネスロジックを気にする必要がないため、このレイヤーでのマルチターミナル適応作業に非常に適しています。
UA検出
マルチ末端適応で最初に解決することは、UA検出問題です。リクエストを終了するには、対応するコンテンツを出力するためにこのデバイスのタイプを知る必要があります。現在、市場に出回っている多数のデバイスと互換性のある非常に成熟したユーザーエージェント機能ライブラリと検出ツールがあります。これがMozillaによって編集されたリストです。その中には、ブラウザ側で実行されているものとサーバーサイドコードレイヤーで実行されるものの両方があります。一部のツールでは、各リクエストのUA情報を解析する責任があるNginx/Apacheモジュールも提供しています。
実際、最後のものをお勧めします。フロントエンド分離に基づくソリューションは、UAプローブがサーバー側でのみ実行できることを決定しますが、プローブコードと機能ライブラリがビジネスコードに結合されている場合、十分に友好的なソリューションではありません。この動作を前方に移動し、nginx/apacheに掛けます。各リクエストのUA情報を解析し、HTTPヘッダーを介してビジネスコードに渡す責任があります。
これを行うことにはいくつかの利点があります：
私たちのコードは、UAの解析方法に注意を払う必要がなくなり、上層から解析された情報を取り出すだけです。同じサーバーに複数のアプリケーションがある場合、同じnginxで解析されたUA情報を一緒に使用して、異なるアプリケーション間の解像度の損失を節約できます。
Tmallが共有するNginxに基づくUA検出ソリューション
TaobaoのTengine Webサーバーは、同様のモジュールngx_http_user_agent_moduleも提供します。
UA検出ツールを選択する際には、機能ライブラリの保守性を考慮する必要があることに言及する価値があります。市場にはますます多くの新しい機器の種類があるため、各デバイスには独立したユーザーエージェントがあります。そのため、機能ライブラリは、機器の変更に適応するための適切な更新戦略とメンテナンス戦略を提供する必要があります。
MVCモードに組み込まれたいくつかの適応
UA情報を取得した後、指定されたUAに基づいて端子適応が実行されるかどうかを考慮する必要があります。 NodeJSレイヤーでさえ、ビジネスロジックのほとんどは欠落していますが、内部をモデル/コントローラー/ビューの3つのモデルに分割します。
最初に上記の図を使用して、いくつかの既存のマルチターミナル適応ソリューションを分析しましょう。
コントローラー上に構築された適応
このソリューションは、それに対処するための最も簡単で最も失礼な方法でなければなりません。同じURLをルーターを介して同じ制御層に渡します。制御層は、レンダリングのためにUA情報を介してデータとモデルのロジックを対応するディスプレイ（ビュー）に配布し、レンダリングレイヤーは、概念前に応じていくつかの端子に適応するテンプレートを提供します。
このソリューションの利点は、データと制御層の統一を維持し、ビジネスロジックをすべての端子に1回だけ適用できることです。ただし、このシナリオは、ディスプレイページなどのインタラクティブの低いアプリケーションにのみ適しています。ビジネスがより複雑になると、各端末のコントローラーに独自の処理ロジックがある場合があります。彼らがまだコントローラーを共有している場合、それはコントローラーを非常に肥大化し、維持するのが難しくなります。これは間違いなく間違った選択です。
ルーター上に構築された適応
上記の問題を解決するために、ルーター上のデバイスを区別し、異なる端子の異なるコントローラーに配布できます。
これは、最も一般的なソリューションの1つでもあり、主に異なる端子に別のアプリケーションセットを使用することで明らかにされています。たとえば、PC TaobaoのホームページとTaobaoホームページのWAPバージョンがwww.taobao.comにアクセスすると、サーバーはTaobaoホームページのWAPバージョンまたはルーターコントロールを介してTaobaoホームページのPCバージョンにリダイレクトします。それらは、2つの完全に独立したアプリケーションセットです。
ただし、このソリューションは間違いなく、データとロジックの一部を共有できない問題をもたらします。さまざまな端子が同じデータとビジネスロジックを共有することはできず、その結果、多くの反復作業が行われ、非効率的です。
この問題を軽減するために、誰かが最適化されたソリューションを提案しました。同じアプリケーションのセットで、各データソースはまだ各モデルに抽象化され、組み合わせのために異なる端子のコントローラーに提供されます。
このソリューションは、以前のデータを共有できない問題を解決します。コントローラーでは、各端末はまだ互いに独立していますが、同じデータソースを一緒に使用できます。少なくとも、データ内の端子タイプの独立したインターフェイスを開発する必要はありません。
上記の2つのルーターベースのソリューションでは、コントローラーが独立しているため、各端末は独自のページに異なるインタラクティブロジックを実装でき、各端末自体に十分な柔軟性を確保できます。これが、ほとんどのアプリケーションがこのソリューションを採用する主な理由でもあります。
ビューレイヤーの上に構築された適応
これは、Taobao注文ページに使用されるソリューションですが、違いは、順序付けページがNodejsレイヤーではなく、全体的なレンダリングレイヤーをブラウザ側に配置することです。ただし、ブラウザであろうとnodejsであろうと、全体的なデザインのアイデアはまだ同じです。
このソリューションでは、ルーター、コントローラー、モデルはデバイス情報に注意を払う必要はなく、端子タイプの判断は処理のためにディスプレイレイヤーに完全に任されています。図のメインモジュールは「ファクトリーを表示」です。モデルとコントローラーがデータとレンダリングロジックに合格した後、ビューファクトリを使用して、デバイス情報やその他の状態（UA情報だけでなく、ネットワーク環境、ユーザーエリアなども）に基づいて多数のプリセットコンポーネントから特定のコンポーネントをつかみ、それらを最終ページに結合します。
このソリューションにはいくつかの利点があります。
上層層は、デバイス情報（UA）に注意を払う必要はありません。複数の端子のビデオは、最終的に最大の関係を示すビューレイヤーによって引き続き処理されます。それは単なるマルチ末端適応ではなく、UA情報に加えて、各ビューコンポーネントを、ネットワーク速度でデフォルトで非表示にするなど、ユーザーのステータスに従ってどのテンプレートを出力するかを決定することもできます。各ビューコンポーネントの異なるテンプレートは、独自の裁量で同じデータとビジネスロジックを使用するかどうかを決定し、非常に柔軟な実装方法を提供します。
しかし、このソリューションが最も複雑であることは明らかです。特に、インタラクティブなアプリケーションシナリオを考慮すると、ルーターとコントローラーがそれほど純粋であり続けることができない可能性があります。特に、コンポーネント自体に分割することはできない比較的強い整合性を持つ一部の企業では、このソリューションは適用できない場合があります。また、一部の単純なビジネスでは、このアーキテクチャを使用することが最良の選択ではないかもしれません。
要約します
上記のソリューションは、それぞれMVCモデルの1つ以上の部分に反映されます。 1つのソリューションがビジネスのニーズを満たしていない場合、複数のソリューションを同時に採用できます。または、ビジネスの複雑さとインタラクティブな属性が、製品がより適しているマルチ末端適応ソリューションを決定することを理解することができます。
ブラウザベースのレスポンシブ設計スキームと比較して、ほとんどの端末検出とレンダリングロジックがサーバーに移行され、NodeJSレイヤーに適応すると、パフォーマンスとユーザーエクスペリエンスが向上します。さらに、いわゆる「クラウド適応」スキームによって引き起こされるコンバージョン品質の問題と比較して、フロントエンド分離に基づく「カスタマイズされた」スキームには存在しません。フロントエンドとバックエンドの分離のための適応ソリューションには、これらの側面において自然な利点があります。
最後に、より柔軟で強力な適応ニーズに適応するために、フロントエンド分離に基づく適応ソリューションはより多くの課題に直面します！