Webアプリケーションアーキテクチャが投資、製品ライフサイクル、肯定的なユーザー感情に与える影響

最近では、「Webアプリケーション」、「フロントエンドアーキテクチャ」、「Web 2.0」、「HTML5アプリケーション」という用語を使用することが流行しています。 しかし、残念なことに、ほとんどの場合、これらの用語を使用するコンテキストは、Webアプリケーションのアーキテクチャの実装と使用のすべての詳細を考慮していないため、常に正しいとは限りません。 今日は建築についてお話します。



この記事を書くきっかけは、ブログhttp://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.htmlに掲載されたことです。 かなり圧縮されており、HTML5 / Mobileを変換する可能性を考慮していないことに注意してください。 ここでは、Webの最新の傾向と、アプリケーションの顧客にとって重要な点（セキュリティなど）を考慮して、アーキテクチャをより詳細に検討しようとしました。



まず、Webアプリケーションの最も一般的なアーキテクチャ、その利点と欠点を、顧客、開発者、ユーザーの3つの観点から見ていきます。 他のオプションも可能ですが、それらは依然として問題のアーキテクチャのサブタイプであり、メイン3つに削減されます。



Webアプリケーションをそのように定義することから始めましょう。 ウィキペディアは、次の定義を提供します。クライアントがブラウザで、サーバーがWebサーバーであるクライアントサーバーアプリケーション。 Webアプリケーションのロジックはサーバーとクライアント間で分散され、データの保存は主にサーバー上で実行され、情報はネットワークを介して交換されます。



ここから、Webアプリケーションを実装するアーキテクチャに直接関連する混乱が始まります。 実際、アプリケーションのロジックはサーバーとクライアントの両方に配置できます。 アーキテクチャが異なると、クライアントとサーバー間でロジックが異なって分散されます。







残念ながら、完全に異なるアーキテクチャを客観的に評価することは不可能です。 以下の基準を使用して評価します。



ユーザー：

応答性/使いやすさ：ページ上のデータを更新し、ページを切り替えます（呼び出し時間）。 インターフェースの豊かさと便利さ、その直感性。

リンク機能：サイトのさまざまなセクションへのブックマークとリンクを保存する機能。

オフライン：ネットワークなしでアプリケーションを実行する機能。



開発者：

開発速度：新しい機能の追加、リファクタリング、開発者とタイプセッター間の開発プロセスの並列化などの速度。

パフォーマンス：最小の計算能力でサーバーからの最速の応答。

スケーラビリティ：情報量またはユーザー数の増加により、計算能力またはディスク容量を増加させる能力。 分散スケーラブルシステムを使用する場合、データの一貫性、アクセシビリティ、分離抵抗（CAP定理）を保証する必要があります。 顧客の要望の増加に伴うアプリケーションの機能/スクリーンショットの数（クライアント側）はこの定義には適用されないことに注意してください-それはむしろ、Webアーキテクチャの種類ではなく、使用されるフレームワークと実行に依存します。

テスト容易性：テストの能力と容易さ（ユニット自動テスト）。



顧客：

機能の拡張性：最小限の時間とお金で機能を構築する能力。

SEO：ユーザーは、任意の検索エンジンを使用してアプリケーションを見つけることができるはずです。

サポート：アプリケーションインフラストラクチャの維持コスト-アプリケーションのサービスに必要なハードウェア、ネットワークインフラストラクチャ、スタッフのコスト。

セキュリティ：アプリケーションの顧客は、ビジネスデータの安全性と他のユーザーに関するデータへのアクセス不能性を確認する必要があります。 主なセキュリティ基準として、クライアントでのアプリケーションの動作の機能を変更する可能性と、これに関連するリスクのみを考慮します。 標準の脅威（たとえば、 https：//www.owasp.org/index.php/Main_Pageで分析）は、比較されたすべてのアーキテクチャで同じです。 考慮されるすべてのアーキテクチャが同様にハッキングの影響を受けやすいという事実のため、サーバーとクライアント間のデータ転送セクションではセキュリティを考慮していません-データ転送チャネルは同じである場合があります。

コンバージョン：ウェブサイト-モバイルまたはデスクトップアプリケーション：モバイルマーケットでアプリケーションを公開する機能、または最小限の追加コストでデスクトップアプリケーションにラップする機能。



おそらく、基準または当社の評価のいくつかは、あなたにとって間違っているように見えるかもしれません。 しかし、この記事の目的は、「何が良いか、何が悪いか」を示すことではなく、より詳細なレビューを行い、選択の可能性を示すことです。



サーバーとブラウザ（クライアント）によって実行されるロールに応じて、Webアプリケーションの主なタイプを識別してみましょう。



タイプ1：サーバーサイドHTML







現時点で最も一般的なアーキテクチャ。 これは、サーバーがHTMLコンテンツを生成し、完全なHTMLページとしてクライアントに送信するという事実に基づいています。

このアーキテクチャは、「Web 1.0」と呼ばれることもあります。これは、このアーキテクチャが最初に登場し、現在はWeb上で支配的であるためです。



応答性/ユーザビリティ： 1/5。 考慮されたアーキテクチャの中で最も最適でないもの。 これは、サーバーとクライアント間で、ビジネスデータ自体だけでなく、その設計にも責任を持つ膨大な量のデータを転送する必要があるという事実によるものです。 ユーザーは、たとえばページのごく一部のみを更新するなどの簡単なアクションに応じて、ページがリロードされるのを待たなければなりません。 クライアントのUIテンプレートは、サーバーで使用されるフレームワークに直接依存します。 モバイルインターネットの制限と大量のデータ送信のため、このアーキテクチャはモバイルセグメントでは実際には機能しません。 即時のデータ更新やリアルタイムの変更を配信する方法はありません。 サーバー側で生成し、既製のコンテンツの形でクライアントを更新することで（AJAX、WebSocketsを介して）リアルタイムの変更の可能性を考慮し、さらにページの一部を置き換えるデザインを行う場合、このアーキテクチャの境界を超えてしまいます。

リンク可能性： 5/5。 問題のアーキテクチャのうち、リンク可能性を実装するのが最も簡単です。 これは、サーバー上で、特定のHTMLコンテンツがデフォルトで1つのURLに割り当てられているためです。

SEO： 5/5。 前の段落と同様、非常に簡単に実装されます-ページのコンテンツは事前に知られています。

開発速度： 5/5。 最も古いアーキテクチャなので、特定のニーズに合わせて任意のサーバー言語とフレームワークを選択できます。

スケーラビリティ ：4/5。 HTMLの生成を検討する場合、最終的に負荷が増加すると、負荷分散のための分散を実装する必要がある瞬間があります。 データベースのスケーリングの状況ははるかに複雑ですが、このタスクは検討中の3つのアーキテクチャすべてと同じで特徴的です。

生産性： 3/5。 トラフィック、速度などの点で応答性とスケーリングに密接に関連しています。 HTML、デザイン、およびビジネスデータ自体を含む最大量のデータを転送する必要があるため、パフォーマンスは低くなります。 したがって、すべての関連情報（レイアウトなど）だけでなく、ページ全体（変更されたビジネスデータだけでなく）のデータを生成する必要があります。

テスト容易性： 4/5。 このアーキテクチャの利点は、フロントエンドのテストに、一般的な場合、JavaScriptの解釈をサポートする特別なツールが必要ないことです（ページのコンテンツが静的であるため）。

安全性： 4/5。 「壊れていないものを壊すことはできません」-アプリケーションの動作のロジック全体がサーバー上にあります。 同時に、データは明確な形式で送信されるため、必要に応じて、セキュリティで保護されたチャネルをお勧めします（これは、サーバーに関連付けられているアーキテクチャに本質的に適用されます）。 すべての保護機能はサーバー側にあります。

コンバージョン：ウェブサイト-モバイルまたはデスクトップアプリケーション： 0/5。 ほとんどの場合、これは単に不可能です。 例外（または、むしろエキゾチック）はまれなケースです。たとえば、サーバーがnode.jsに実装されていて、大きなデータベースがない場合などです。 または、サードパーティのWebサービスを使用してデータを受信する場合（ただし、これはアーキテクチャのより高度なバージョンです）。 この方法では、node-webkitまたはピアを使用してアプリケーションをラップします。

オフライン： 2/5。 HTML5仕様で導入されたサーバーマニフェストを使用して実装されます。 ブラウザがこの仕様をサポートしている場合、アプリケーションのすべてのページがキャッシュされ、ネットワークから切断されると、キャッシュされたページがユーザーに表示されます。



タイプ2：JS生成ウィジェット（AJAX）







最初のタイプのアーキテクチャの開発。 違いは、ブラウザーに表示されるページがウィジェット（機能的に独立したブロック）で構成されることです。 これらのウィジェットのデータは、サーバーからのAJAXリクエストでロードされます。 JSONの形式で、または既にJavaScriptテンプレート/ビニングを使用している場合は、ページコンテンツに変換されます。 HTMLの一部をロードするオプションを使用すると、クライアント側のJavaScript-MV *フレームワークが不要になります。この場合、たとえばjQueryなど、より単純なもので処理できます。 対話性を減らすことにより、開発速度を加速し、機能をより安価で信頼性の高いものにします。



主な利点は、クライアントが更新を要求しているページのその部分を更新するために、サーバーからデータのみが送信されることです。 良い点は、ウィジェットが機能的に分離されていることです。特定のウィジェットが担当するページの一部の機能を変更しても、すべてに影響するわけではありません。



応答性/ユーザビリティ ：3/5。 ページの一部のみを更新するために送信されるデータの量は、ページ全体よりもはるかに少ないため、応答性が向上します。 ただし、ページはウィジェットのセットであるため、Webアプリケーションに適用されるUIテンプレートは、適用されるUIフレームワークによって制限されます。 このようなWebページの「コールドスタート」（最初のフルロード）がもう少し長くなることに言及する価値があります。 サーバー上で完全に生成およびキャッシュされたコンテンツは、クライアント上で即座に表示できます。 ここでは、ウィジェットのデータの取得と、原則としてテンプレートの作成に時間がかかります。 したがって、最初にサイトにアクセスしたとき、すぐに開くことはありませんが、最初のタイプのアーキテクチャと比較すると、作業がはるかに快適になります。 また、「 http://www.yahoo.com/で行われているように」「部分的に」ダウンロードを実装する可能性について言及する価値があります 。

リンク可能性 ：2/5。 特別なツールとメカニズムが必要です。 原則として、Hash-Bangメカニズムが使用されます。

SEO ：2/5。 これらのタスクには特別なメカニズムがあります。 たとえば、このアーキテクチャのサイトをプロモートするために、プロモートされるページのリストを事前に定義し、パラメーターおよび修飾子なしでそれらのページの静的URLを作成することができます。

開発速度： 3/5。 サーバー側の技術に関する知識だけでなく、クライアント側でのJavaScriptフレームワークの使用も必要です。 サーバー側の類似性の実装も必要です。

パフォーマンス： 4/5。 HTMLコンテンツの生成に費やされる時間とリソースは、アプリケーションがデータベースからのデータの取得とテンプレート生成前のデータの処理に費やす時間に比べて比較的短いです。 このアーキテクチャの拡張タイプ（データがJSONの形式で送信される場合）を使用すると、クライアントとサーバー間のトラフィックは減少しますが、アプリケーションから抽象レベルが追加されます。データベースからの抽出->データ処理、JSONでのシリアル化-> API：>解析JSON-> HTMLへのクライアントデータオブジェクトバインディング。

スケーラビリティ：最初のタイプのアーキテクチャに似ています。

テスト容易性： 1/5。 サーバー側、クライアントコード、およびウィジェットを更新するためのデータを返すWebサービスでのテストが必要です。

安全性： 4/5。 ロジックの一部はクライアント側のJavaScriptで実行され、攻撃者が簡単に変更できます。

変換：Webサイト-モバイルまたはデスクトップアプリケーション：最初のタイプのアーキテクチャに似ています。

オフライン： 1/5。 この場合、マニフェストメカニズムも機能しますが、ウィジェットに表示されるデータを更新またはキャッシュするときに問題が発生します。 マニフェストではサーバーからキャッシュされるファイルの名前のみを指定できるため、この機能を追加で実装する必要があります。 マニフェストにキャッシュされているウィジェットテンプレートファイルの名前とページの動作ロジックとの関係を整理するには、追加の作業が必要です。



タイプ3：サービス指向の単一ページWebアプリ（Web 2.0、HTML5アプリ）







ここで、「Web 2.0」という用語はここで使用するのはまったく正しくないという小さな発言をしたいと思います。 Tim O'Reillyによって最初に紹介されたのは、「ネットワークインタラクションを考慮に入れることで、より多くの人が使用するほど良くなるシステムを設計するための方法論」です。 また、Web 2.0の特性は、情報素材の繰り返しの検証にユーザーを引き付ける原理です。 実際、「Web 2.0」という用語は、ユーザー自身によって積極的に開発および改善されているプロジェクトやサービスを指します。ブログ、Wiki、ソーシャルネットワークなどです。このことから、Web 2.0は1つのテクノロジーまたはテクノロジーセットに結び付けられていません。



問題のアーキテクチャの本質は、特定のWebサービスにアクセスするときにビジネスデータのみを受信するJavaScriptコードのコンテナであるサーバーからHTMLページがロードされることです。 そのうち、JavaScriptアプリケーションはページのHTMLコンテンツを生成します。 実際、3番目のタイプのアーキテクチャは以前のタイプの開発であり、機能の一部をクライアント側に転送することにより、独立したかなり複雑なJavaScriptアプリケーションの完全なレベルにそれをもたらします。 2番目のタイプのアーキテクチャは、通常、相互接続された構造化された非常に多くの機能を誇ることはできません。



また、完全にオフラインで動作するJavaScriptアプリケーションはほとんど作成されないことに注意してください （まれな例外： http://www.wakanda.org/、http://html.adobe.com/edge/code/、http：/ /cdn.sencha.io/touch/sencha-touch-2.2.1/examples/kitchensink/index.html、http：//rad-js.com/ ）、このアプローチにより、簡単な逆変換が可能になります-既存のアプリケーションをウェブ



応答性/ユーザビリティ： 5/5。 情報を更新するために送信されるデータの量は最小限であるため、最大の応答性が得られます。 UIはJavaScriptを使用して生成され、必要なオプションを実装できます。 微妙な点は、JavaScriptのマルチスレッドの問題です。この場合、大量のビジネスデータの処理はWebサービスの側に移動する必要があります）

リンク可能性： 1/5。 特別なツールとメカニズムだけでなく、たとえばHash-Bangメカニズムを使用できるフレームワークも必要です。

SEO： 1/5。 最も重いプロモーションアーキテクチャ。 アプリケーション全体が直接プロモートされている場合、問題はありません。アプリケーションコンテナをプロモートすることは可能です。 アプリケーションパーツのローテーションが必要な場合、現時点ですべてのメカニズムのうち、次のものに類似したもののみがあります。http： //googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.htmlおよびhttp：// seodacha .ru /ニュース/ yandeks-predlagaet-reshenie-dlya-indeksacii-ajax-saytov 。 多かれ少なかれ大規模な検索エンジンごとに、このプロセスを標準化する独自の方法が用意されています。

開発速度： 2/5。 Webサービスの開発と、より専門的な（アプリケーションアーキテクチャの構築）JavaScriptフレームワークの使用が必要です。 アーキテクチャの新規性により、このアプローチで本当に高品質のWebサイト/システムを作成できる専門家はほとんどいないことに言及する価値があります。 開発され、十分に開発されたツール、フレームワーク、アプローチはほとんどありません。

パフォーマンス： 5/5。 このアーキテクチャでは、サーバーがブラウザーにJSアプリケーションを送信するだけでよいため、この特性はサーバー側への影響が最も少なくなります。 クライアント側では、ブラウザのパフォーマンスと種類が最も重要です。

スケーラビリティ： 5/5。 すべてのWebロジックはクライアント側に引き継がれ、コンテンツを生成するためにサーバーに負荷はかかりません。 ユーザー数の増加に伴い、スケーリングはビジネスデータを提供するWebサービスに対してのみ必要になります。

テスト容易性： 3/5。 Webサービスとクライアント側のJavaScriptコードのテストが必要です。

セキュリティ： 0/5。 すべてのロジックはクライアント側のJavaScriptで実行され、攻撃者が簡単に変更できます。 したがって、安全なシステムのためには、オープンソースアプリケーションhttp://aosabook.org/en/index.htmlの編成の特性を考慮したプロアクティブなアーキテクチャを開発する必要があります。たとえば、サードパーティのキー配布チャネルのオプションです。

コンバージョン：ウェブサイト-モバイルまたはデスクトップアプリケーション： 5/5。 このサイトは、 http：//phonegap.com/、https: //github.com/rogerwang/node-webkit、https ://code.google.com/p/chromiumembedded/などのプラットフォームを使用して静かにアプリケーションに変わりつつありますそのような。

オフライン： 5/5。 このアーキテクチャは完全なアプリケーションです。 ストレージ（localstorageなど）を使用して、個々のデータとアプリケーション自体の一部の両方を保存することができます。 もう1つの利点は、データのストレージと管理を完全にオフラインモードに切り替えることができることです。 一方、以前の2つのアーキテクチャはオフラインで部分的にしか機能していません。 ここで、不足しているデータをスタブに置き換えることができます。警告ウィンドウを表示したり、ローカルストレージのデータを使用して、同期を後で行うことができます。



- , , — . , «», , , , - .



, , — . , -.







; .