シングルページアプリケーション：利点と欠点[終了]

SPAとその利点について読みました。私はそれらのほとんどが納得できないと思います。私の疑問を呼び起こす3つの利点があります。

質問： あなたはSPAの擁護者として行動し、最初の3つのステートメントについて私が間違っていることを証明できますか？

                              === ADVANTAGES ===

1. SPAは非常に応答性の高いサイトに非常に適しています。

すべての中間状態に対してサーバー側レンダリングを実装するのは困難です。小さなビューステートはURLにうまくマップできません。

シングルページアプリは、HTMLを取得するためのサーバーラウンドトリップを必要とせずにUIの任意の部分を再描画する機能によって区別されます。これは、データを処理するモデルレイヤーとモデルから読み取るビューレイヤーを使用することにより、データをデータのプレゼンテーションから分離することによって実現されます。

非SPAのモデルレイヤーを保持することの何が問題になっていますか？SPAはクライアント側のMVCと互換性のある唯一のアーキテクチャですか？

2. SPAを使用すると、ページをダウンロードするためにサーバーに追加のクエリを使用する必要がありません。

ええと、ユーザーがあなたのサイトにアクセスしている間にダウンロードできるページ数は？2、3？代わりに、別のセキュリティ問題が発生し、ログインページ、管理ページなどを別々のページに分ける必要があります。次に、SPAアーキテクチャと競合します。

3.他の利点がありますか？他のことについては聞かないでください。

                            === DISADVANTAGES ===

1. クライアントはJavaScriptを有効にする必要があります。
2. サイトへのエントリポイントは1つだけです。
3. セキュリティ。

PS私はSPAおよび非SPAプロジェクトに取り組んできました。理解を深める必要があるので、これらの質問をしています。SPAサポーターに害を及ぼすことは決してありません。SPAについてもう少し読むように言わないでください。それについてのあなたの考えを聞きたいだけです。

最も人気のあるSPAサイトの1つであるGMailを見てみましょう。

1. SPAは非常に応答性の高いサイトに非常に適しています。

サーバー側のレンダリングは、URLに＃ハッシュを保持するなどの単純な手法や、最近ではHTML5をpushState使用する場合ほど難しくありません。このアプローチでは、Webアプリの正確な状態がページURLに埋め込まれます。GMailと同様に、メールを開くたびに、特別なハッシュタグがURLに追加されます。コピーして他のブラウザウィンドウに貼り付けると、まったく同じメールを開くことができます（認証できる場合）。このアプローチは、より伝統的なクエリ文字列に直接マッピングされます。違いは、実行のみです。HTML5 pushState（）を#hash使用すると、最初のリクエストでサーバー上で解決し、その後のリクエストでajaxを介してロードできる完全にクラシックなURLを削除して使用できます。

2. SPAを使用すると、ページをダウンロードするためにサーバーに追加のクエリを使用する必要がありません。

私のWebサイトへのアクセス中にユーザーがダウンロードしたページの数？メールアカウントを開いたときに実際に読むメールの数。一度に50以上を読みました。現在、メールの構造はほとんど同じです。サーバー側のレンダリングスキームを使用する場合、サーバーはリクエストごとにレンダリングします（通常の場合）。-セキュリティ上の問題-サイトの構造に完全に依存する管理者/ログイン用に個別のページを保持する/しないでください。たとえば、paytm.comを使用して、WebサイトSPAを作成しても、すべてのエンドポイントをすべて開くことを意味しません。ユーザー私は自分のスパWebサイトでフォーム認証を使用していることを意味します。-おそらく最も使用されているSPAフレームワークAngular JSでは、開発者はWebサイトからHTMLテンプル全体をロードできるため、ユーザー認証レベルに応じて実行できます。すべての認証タイプのHTMLを事前にロードしていません

3.他の利点はありますか？他のことについては聞かないでください。

• 最近では、クライアントがJavaScriptを有効にしたブラウザーを備えていると想定しても問題ありません。
• サイトの1つのエントリポイントのみ。以前に述べたように、状態の維持は可能です。エントリポイントはいくつでも持つことができますが、必ず1つ持つ必要があります。
• SPAユーザーであっても、自分が適切な権限を持っているものだけを見ることができます。すべてを一度に注入する必要はありません。diff htmlテンプレートとjavascript asyncのロードもSPAの有効な部分です。

私が考えることができる利点は次のとおりです。

1. HTMLをレンダリングするには、サイトにアクセスするすべてのユーザーがこれを実行しているため、明らかにいくつかのリソースが必要です。また、主要なロジックのレンダリングだけでなく、サーバー側ではなくクライアント側でも行われるようになりました。
2. 日付時刻の問題-クライアントにUTC時刻を事前に設定された形式で指定し、JavaScriptで処理するタイムゾーンについても気にしません。これは、ユーザーのIPから取得した場所に基づいてタイムゾーンを推測しなければならない場合に非常に有利です。
3. 変数を設定すると、その変数がそこにあることがわかるので、私にとって、状態はSPAでより適切に維持されます。これにより、Webページではなくアプリを開発しているような感覚になります。これは通常、フードパンダ、フリップカート、アマゾンなどのサイトを作成するのに役立ちます。クライアント側の状態を使用していない場合は、高価なセッションを使用しているためです。
4. Webサイトは確かに非常に反応が速いです。SPA以外のWebサイトで電卓を作ってみます。極端な例をとります（奇妙なことですが）。

コメントからの更新

ソケットとロングポーリングについて誰も言及していないようです。別のクライアントからログアウトしてモバイルアプリと言う場合は、ブラウザーもログアウトする必要があります。SPAを使用しない場合、リダイレクトがあるたびにソケット接続を再作成する必要があります。これは、通知、プロファイルの更新などのデータの更新でも機能するはずです。

別の見方：あなたのウェブサイトは別として、あなたのプロジェクトはネイティブモバイルアプリを含みますか？はいの場合、サーバー（JSONなど）から生のデータをそのネイティブアプリに供給し、クライアント側で処理してレンダリングします。したがって、このアサーションでは、クライアント側のレンダリングモデルをすでに実行しています。さて、問題は、プロジェクトのウェブサイトバージョンに同じモデルを使用してはならないのはなぜですか。簡単なことです。次に、SEOの利点と共有可能/ブックマーク可能なURLの利便性のためだけにサーバー側のページをレンダリングするかどうかが問題になります。

私は実用主義者なので、これをコストと利益の観点から見てみます。

私が与える不利な点については、それらが解決可能であることを認識しています。だからこそ、私は何も白黒ではなく、むしろコストと利益を考えていません。

メリット

• より簡単な状態追跡-2ページのロード間の状態を記憶するためにCookie、フォーム送信、ローカルストレージ、セッションストレージなどを使用する必要はありません。
• すべてのページにあるボイラープレートコンテンツ（ヘッダー、フッター、ロゴ、著作権バナーなど）は、通常のブラウザーセッションごとに1回だけ読み込まれます。
• 「ページ」を切り替える際のオーバーヘッドの待ち時間はありません。

短所

• パフォーマンスモニタリング-手で縛られた：ほとんどのブラウザレベルのパフォーマンスモニタリングソリューションは、最初のバイトまでの時間、DOMを構築する時間、HTMLのネットワークラウンドトリップ、onloadイベントなど、ページのロード時間のみに焦点を当ててきました。ページの更新AJAXを介したポストロードは測定されません。リンクをクリックしたり、タイマーを開始したり、AJAXの結果をレンダリングした後にタイマーを終了したり、フィードバックを送信したりするなど、明示的な測定を記録するコードを計測できるソリューションがあります。たとえば、New Relicはこの機能をサポートしています。SPAを使用することで、いくつかの可能なツールに縛られることになります。
• セキュリティ/ペネトレーションテスト-手作業：ページ全体がSPAフレームワークによって動的に構築されている場合、自動セキュリティスキャンではリンクを検出するのが難しい場合があります。これにはおそらく解決策がありますが、繰り返しになりますが、あなたは自分自身を制限しています。
• バンドリング：最初のページのロード時にWebサイト全体に必要なすべてのコードをダウンロードしているときに、低帯域幅の接続でひどく実行される状況に陥るのは簡単です。JavaScriptファイルとCSSファイルをバンドルして、進むにつれてより自然なチャンクでロードしようとすることができますが、今はそのマッピングを維持し、意図しないファイルが未実現の依存関係から取り込まれるのを監視する必要があります（たまたま私に起こりました）。繰り返しますが、解決可能ですが、コストがかかります。
• ビッグバンリファクタリング：リスクを最小限に抑えるために、あるフレームワークから別のフレームワークに切り替えるなど、アーキテクチャーに大きな変更を加えたい場合は、増分変更を行うことが望ましいです。つまり、新しいものの使用を開始し、ページごと、機能ごとなどの何らかの基準で移行してから、古いものを削除します。従来のマルチページアプリでは、1つのページをAngularからReactに切り替え、次のスプリントで別のページを切り替えることができました。SPAがあれば、それは全部かゼロかです。変更したい場合は、アプリケーション全体を一度に変更する必要があります。
• ナビゲーションの複雑性：ツールは、history.js、Angular 2などのSPAのナビゲーションコンテキストを維持するために存在し、そのほとんどはURLフレームワーク（＃）または新しい履歴APIに依存しています。すべてのページが個別のページである場合、それは必要ありません。
• コードを計算する複雑さ：Webサイトは当然ページと見なされます。マルチページアプリは通常、コードをページごとに分割するので、保守性が向上します。

繰り返しますが、これらの問題はすべて、ある程度のコストで解決できることを認識しています。しかし、そもそも最初は回避できたであろう問題を解決するために、すべての時間を費やしている段階があります。メリットと、それがあなたにとってどれほど重要であるかに戻ります。

短所

1.クライアントはJavaScriptを有効にする必要があります。はい、これはSPAの明らかな欠点です。私の場合、ユーザーがJavaScriptを有効にすることを期待できることはわかっています。できない場合は、SPA、期間を行うことはできません。これは、.NET Frameworkがインストールされていないマシンに.NETアプリをデプロイしようとするようなものです。

2.サイトへのエントリポイントは1つだけです。SammyJSを使用してこの問題を解決します。ルーティングを適切に設定するための2〜3日の作業。人々は、正しく機能するディープリンクブックマークをアプリに作成できます。サーバーは1つのエンドポイントを公開するだけで済みます-「このアプリのHTML + CSS + JSを提供してください」エンドポイント（プリコンパイルされたアプリケーションのダウンロード/更新の場所と考えてください）-作成するクライアント側JavaScriptアプリケーションへの実際のエントリを処理します。

3.セキュリティ。この問題はSPAに固有のものではありません。「古い」クライアントサーバーアプリ（ページ間のリンクにハイパーテキストを使用するHATEOASモデル）がある場合とまったく同じ方法でセキュリティに対処する必要があります。それは、ユーザーがJavaScriptではなくリクエストを行っていること、そして結果がJSONまたは何らかのデータ形式ではなくHTMLであるということだけです。非SPAアプリではサーバー上の個々のページを保護する必要がありますが、SPAアプリではデータエンドポイントを保護する必要があります。（そして、クライアントがすべてのコードにアクセスできないようにしたい場合は、ダウンロード可能なJavaScriptも別々の領域に分割する必要があります。私はそれを私のSammyJSベースのルーティングシステムに結び付けるだけで、ブラウザーが要求するのはユーザーの役割の初期ロードに基づいて、クライアントがアクセスする必要があることをクライアントが知っていること、

メリット

1. 多くの場合、SPAのアーキテクチャ上の主な利点（めったに言及されることはありません）は、アプリの「雑談」の大幅な削減です。クライアントでのほとんどの処理（結局のところ全体）を処理するように適切に設計すると、サーバーへの要求の数（「ユーザーエクスペリエンスを破壊する503エラーの可能性」を参照）が劇的に減少します。実際には、SPAは、それが可能である完全にオフライン処理、行うことになり、巨大ないくつかの状況では。

2. 正しく実行すれば、クライアント側のレンダリングの方がパフォーマンスは確実に向上しますが、これがSPAを構築する最も説得力のある理由ではありません。（結局のところ、ネットワーク速度は向上しています。）これだけに基づいてSPAを主張しないでください。

3. UIデザインの柔軟性は、おそらく私が見つけたもう1つの大きな利点です。私は（JavaScriptでSDKで）私のAPIを定義したら、私は完全に私のフロントエンドを書き換えることができたゼロはさておき、いくつかの静的リソースファイルからサーバーへの影響。従来のMVCアプリでそれを試してみてください！:)（これは、心配するAPIのライブデプロイメントとバージョンの一貫性がある場合に役立ちます。）

つまり、オフライン処理が必要な場合（または少なくともクライアントがサーバーの不定期な停止に耐えられるようにしたい場合）-独自のハードウェアコストを大幅に削減し、JavaScriptと最新のブラウザーを想定できる場合は、SPAが必要です。他の場合では、それはトレードオフの多くです。

SPAの1つの主要な欠点-SEO。最近、GoogleとBingがクロール中にJavaScriptを実行してAjaxベースのページのインデックスを作成し始めましたが、それでも多くの場合、ページのインデックスが正しく作成されていません。

SPAを開発している間、おそらくすべてのサイトをポストレンダリングし、クローラーが使用する静的なHTMLスナップショットを作成することにより、SEOの問題を処理する必要があります。これには、適切なインフラストラクチャへの確実な投資が必要です。

アップデート19.06.16：

少し前にこの答えを書いて以来、私はシングルページアプリ（つまり、AngularJS 1.x）ではるかに多くの経験を積みました。

私の意見では、SPAアプリケーションの主な欠点はSEOであるため、「ダッシュボード」アプリケーションの種類にのみ限定されます。さらに、従来のソリューションと比較して、キャッシングがはるかに困難になります。たとえば、ASP.NETのキャッシングは非常に簡単です。OutputCachingをオンにするだけで十分です。HTMLページ全体がURL（またはその他のパラメーター）に従ってキャッシュされます。ただし、SPAでは、自分でキャッシュを処理する必要があります（2次キャッシュ、テンプレートキャッシュなどのソリューションを使用して）。

SPAがデータドリブンアプリケーションに最適であると主張したいと思います。もちろんgmailはすべてデータに関するものなので、SPAの候補として最適です。

しかし、ページが主に表示用である場合（例えば、利用規約ページ）、SPAは完全に過剰です。

特定のページに応じて、SPAと静的/ MVCスタイルの両方のページが混在するサイトがスイートスポットになると思います。

たとえば、私が構築している1つのサイトで、ユーザーは標準のMVCインデックスページにアクセスします。しかし、実際のアプリケーションにアクセスすると、SPAが呼び出されます。これのもう1つの利点は、SPAのロード時間がホームページではなく、アプリページにあることです。ホームページでの読み込み時間が初めてのサイトユーザーの注意散漫になる可能性があります。

このシナリオは、フラッシュの使用に少し似ています。数年の経験の後、負荷要因のために、Flashのみのサイトの数はほぼゼロに減少しました。しかし、ページコンポーネントとして、それはまだ使用されています。

24時間365日モードでサーバーが最大容量で稼働しているgoogle、amazonなどの企業の場合、トラフィックを削減することは、ハードウェアの削減、エネルギーの削減、メンテナンスの削減という実質的なコストを意味します。CPU使用率をサーバーからクライアントにシフトすることで成果が上がり、SPAが輝きます。利点は断然太りすぎの欠点です。したがって、SPAかどうかは、ユースケースに大きく依存します。

SPAの（Web開発者にとって）おそらくそれほど明白ではない別の使用例に言及するために、私は現在、組み込みシステムにGUIを実装する方法を探しています。ブラウザベースのアーキテクチャは魅力的だと思います。従来、組み込みシステムのUIには、Java、Qt、wxなどの商用フレームワークなど、多くの可能性はありませんでした。数年前、アドビはフラッシュで市場に参入しようとしましたが、それほど成功していないようです。

今日、「組み込みシステム」は数年前のメインフレームと同じくらい強力であるので、RESTを介してコントロールユニットに接続されたブラウザベースのUIが可能なソリューションです。利点は、UIのツールの巨大なパレットを無料で提供することです。（たとえば、Qtには、販売済みユニットあたり20〜30ドルのロイヤリティ料に加えて、開発者あたり3000〜4000ドルが必要です）

そのようなアーキテクチャの場合、SPAには多くの利点があります。たとえば、デスクトップアプリケーション開発者にとってより身近な開発アプローチ、サーバーアクセスの削減（多くの場合、自動車業界では、UIとシステムマドルは、システムパーツにRT OSがある別個のハードウェアです）。

唯一のクライアントは組み込みブラウザーであるため、JSの可用性、サーバー側のロギング、セキュリティなどの前述の欠点はもう考慮されません。

2. SPAを使用すると、ページをダウンロードするためにサーバーに追加のクエリを使用する必要がありません。

私はまだ多くを学ぶ必要がありますが、SPAについて学び始めて以来、私はそれらを愛しています。

この特定のポイントは、大きな違いを生む可能性があります。

SPA以外の多くのWebアプリでは、ajaxリクエストを行うページにコンテンツを取得して追加することがわかります。したがって、SPAは次の点を考慮すればさらに良いと思います。ajaxを使用して取得および表示されるコンテンツがページ全体である場合はどうでしょうか。ページのごく一部ではありませんか？

シナリオを紹介しましょう。次の2つのページがあるとします。

1. 製品一覧のページ
2. 特定の製品の詳細を表示するページ

リストページにいることを考慮してください。次に、製品をクリックして詳細を表示します。クライアント側のアプリは2つのajaxリクエストをトリガーします。

1. 製品の詳細を含むjsonオブジェクトを取得するリクエスト
2. 製品の詳細が挿入されるHTMLテンプレートを取得するリクエスト

次に、クライアント側アプリがデータをhtmlテンプレートに挿入して表示します。

次に、リストに戻り（これに対する要求は行われません！）、別の製品を開きます。今回は、製品の詳細を取得するためのajaxリクエストのみがあります。HTMLテンプレートは同じになるので、再度ダウンロードする必要はありません。

非SPAでは、製品の詳細を開いたときに1つの要求しか行わなかったと言うかもしれませんが、このシナリオでは2つ行いました。はい。しかし、全体的な観点からは利益が得られます。多くのページをナビゲートすると、リクエストの数は少なくなります。また、HTMLテンプレートが再利用されるため、クライアント側とサーバー間で転送されるデータも少なくなります。また、すべてのページに存在するすべてのcss、画像、JavaScriptファイルをすべてのリクエストでダウンロードする必要はありません。

また、サーバー側の言語がJavaであると考えてみましょう。私が言及した2つのリクエストを分析すると、1つはデータをダウンロードし（ビューファイルをロードしてビューレンダリングエンジンを呼び出す必要はありません）、他のダウンロードと静的HTMLテンプレートを取得して、HTTP Webサーバーを取得できるようにしますJavaアプリケーションサーバーを呼び出さなくても、直接計算されません。

最後に、大企業がSPAを使用しています：Facebook、GMail、Amazon。彼らは遊んでいません、彼らはこれらすべてを研究している最高のエンジニアを持っています。したがって、利点が見当たらない場合は、最初にそれらを信頼して、将来的にそれらを発見することを期待できます。

ただし、優れたSPAデザインパターンを使用することが重要です。AngularJSのようなフレームワークを使用できます。混乱を招く可能性があるため、優れたデザインパターンを使用せずにSPAを実装しないでください。

短所：技術的には、SPAの設計と初期開発は複雑であり、回避することができます。このSPAを使用しないその他の理由は次のとおりです。

• a）セキュリティ：シングルページアプリケーションは、クロスサイトスクリプティング（XSS）により、従来のページと比較して安全性が低くなります。
• b）メモリリーク：JavaScriptのメモリリークにより、強力なコンピュータの速度が低下することさえあります。従来のWebサイトはページ間をナビゲートすることを奨励しているため、前のページによって引き起こされたメモリリークはほとんど取り除かれ、残留物が少なくなります。
• c）クライアントはSPAを実行するためにJavaScriptを有効にする必要がありますが、マルチページアプリケーションではJavaScriptを完全に回避できます。
• d）SPAが最適なサイズに大きくなり、待機時間が長くなります。例：接続が遅いGmailで作業しています。

上記とは別に、その他のアーキテクチャ上の制限としては、ナビゲーションデータの損失、ブラウザにナビゲーション履歴のログがないこと、およびセレンを使用した自動機能テストの難しさがあります。

このリンクは、シングルページアプリケーションの利点と欠点を説明しています。

私の開発では、SPAを使用することの2つの明確な利点を発見しました。これは、従来のWebアプリでは次のことを達成できないと言っているのではなく、追加の不利な点を導入することなく、次第にメリットが見られるということです。

• 新しいコンテンツのレンダリングが常に、または新しいHTMLページに対するhttpサーバー要求であるとは限らないため、サーバー要求が少なくなる可能性があります。しかし、新しいコンテンツはデータを取り込むためにAjax呼び出しを簡単に必要とする可能性がありますが、そのデータはそれ自体とマークアップよりも徐々に軽量になる可能性があるため、可能性を示します。

• 「状態」を維持する機能。簡単に言うと、アプリへのエントリ時に変数を設定します。変数を渡したり、ローカルストレージパターンに設定したりせずに、ユーザーエクスペリエンス全体を通じて他のコンポーネントで使用できるようになります。ただし、この機能をインテリジェントに管理することは、トップレベルのスコープを整理するための鍵です。

JSを必要とする（Webアプリに必要なものではありません）以外に、私の意見では、SPAに固有のものではないか、良い習慣と開発パターンによって軽減できる可能性があります。

サーバー側でセキュリティとAPIの安定性に対処する方法を最初に定義せずに、SPAの使用を検討しないようにしてください。次に、SPAを使用することの真の利点のいくつかを確認します。具体的には、セキュリティのためにOAUTH 2.0を実装するRESTfulサーバーを使用する場合、開発と保守のコストを削減できる懸念事項を2つの根本的に分離することになります。

1. これにより、セッション（およびセキュリティ）がSPAに移動し、サーバーがそのオーバーヘッドから解放されます。
2. APIが安定し、簡単に拡張できるようになります。

以前に示唆されましたが、明示されていません。AndroidおよびAppleアプリケーションをデプロイすることが目的である場合、ブラウザー（AndroidまたはApple）で画面をホストするネイティブ呼び出しによってラップされるJavaScript SPAを作成すると、AppleコードベースとAndroidコードベースの両方を維持する必要がなくなります。

これは古い質問であることを理解していますが、単一ページアプリケーションの別の欠点を追加したいと思います。

HTMLなどのフォーマット言語ではなく、データ言語（XMLやJSONなど）で結果を返すAPIを構築すると、企業間（B2B）アプリケーションなど、アプリケーションの相互運用性が向上します。このような相互運用性には大きなメリットがありますが、人々がソフトウェアを作成してデータを「マイニング」（または盗用）することができます。この特定の欠点は、データ言語を使用するすべてのAPIに共通であり、SPAには一般的ではありません（実際に、事前にレンダリングされたHTMLをサーバーに要求するSPAはこれを回避しますが、モデルとビューの分離が不十分です）。この不利益によってもたらされるこのリスクは、リクエストの制限や接続のブロックなど、さまざまな手段によって軽減できます。