シングルページアプリケーション：長所と短所

Question

私はSPAについて読みました、そしてそれは利点です。私はそれらのほとんどが説得力がないと思います。私の疑問をそそる3つの利点があります。

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

 === ADVANTAGES ===

1。非常にレスポンシブなサイトにはSPAは非常に優れています。

サーバーサイドレンダリングは、すべての中間状態に実装するのは困難です - 小さなビュー状態はURLにうまくマッピングされません。

シングルページアプリは、HTMLを取得するためにサーバーのラウンドトリップを必要とせずにUIの任意の部分を再描画できるという点で優れています。これは、データを処理するモデル層とモデルから読み取るビュー層を用意して、データの表示からデータを分離することによって実現されます。

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

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

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

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

 === DISADVANTAGES ===

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

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

Parv Sharma · Accepted Answer

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

1。非常にレスポンシブなサイトにはSPAは非常に優れています。

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

2。 SPAを使用すると、ページをダウンロードするためにサーバに余分なクエリを使用する必要はありません。

私のWebサイトへの訪問中にユーザーがダウンロードしたページ数彼/彼女が彼/彼女のメールアカウントを開いたときに実際にいくつかのメールを読むか。私は一気に> 50を読んだ。今すぐメールの構造はほぼ同じです。サーバーサイドのレンダリングスキームを使用する場合、サーバーはリクエストごとにレンダリングします（通常の場合）。 - セキュリティ上の問題 - 例えばあなたのサイトの構造に完全に依存するadmins/loginのために別々のページを残すべきではない/例えばpaytm.comを取るべきであるウェブサイトSPAを作ることはあなたがすべてのエンドポイントを開くことを意味しませんusers私は私のspa Webサイトでforms authを使用しているということです。 - おそらく最も使用されているSPAフレームワークAngular JSでは、開発者はWebサイトからhtmlテンプル全体をロードできるため、ユーザー認証レベルに応じて実行できます。すべての認証タイプのHTMLを事前にロードすることはSPAではありません。

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

最近では、クライアントがJavascript対応のブラウザを使用することになります。
サイトのエントリポイントは1つだけです。私が以前に述べたように状態の維持は可能ですあなたが望むようにあなたはいくつでもエントリーポイントを持つことができますが、あなたは確かにそれを持つべきです。
sPAユーザーでさえ彼が適切な権利を持っているものだけを見る。あなたは一度にすべてのものを注入する必要はありません。 diff HTMLテンプレートとJavaScript asyncのロードもSPAの有効な部分です。

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

hTMLをレンダリングすることは明らかにあなたのサイトを訪問するすべてのユーザーがこれをやっている今いくつかのリソースを取ります。また、主要なロジックのレンダリングだけでなく、サーバー側ではなくクライアント側でも行われるようになりました。
日付時刻の問題 - クライアントのUTC時刻は事前に設定された形式であり、javascriptにそれを処理させるタイムゾーンについても気にしないでください。これは、ユーザーIPから派生した場所に基づいてタイムゾーンを推測しなければならなかった場合に非常に有利です。
変数を設定したら、それがそこにあることを知っているので、私にとって状態はSPAでよりうまく維持されています。これは、Webページではなくアプリを開発しているように感じます。これはfoodpanda、flipkart、Amazonのようなサイトを作るのに大いに役立ちます。クライアント側の状態を使用していないのであれば、高価なセッションを使用しているからです。
ウェブサイトはきわめて応答性が高い - 私はこの例として極端な例を挙げて、SPA以外のウェブサイトで電卓を作ってみます（私はその奇妙なことを知っています）。

コメントからの更新

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

別の見方：あなたのウェブサイト以外に、あなたのプロジェクトはネイティブのモバイルアプリを含みますか？もしそうなら、あなたはおそらく生のデータをサーバー（すなわちJSON）からそのネイティブアプリに供給し、それをレンダリングするためにクライアントサイドの処理をすることでしょう、正しいですか？だから、この主張で、あなたはすでにクライアントサイドのレンダリングモデルをやっています。今度は、プロジェクトのWebサイト版に同じモデルを使用しないでください。非常に簡単です。それから質問はあなたがSEOの利益と共有可能な/ブックマーク可能なURLの利便性のためだけにサーバーサイドページをレンダリングしたいかどうかになります

Brandon · Answer

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

私が与えるどんな不利益についても、私はそれらが解決可能であることを認識していることに注意してください。だからこそ、私は白黒のものではなく、費用と利益を考えています。

利点

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

デメリット

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

繰り返しになりますが、これらの問題はいずれもある程度のコストで解決可能です。しかし、そもそも避けられたかもしれない問題を解決するためにあなたが全時間を費やしているという点があります。それは利益とそれらがあなたにとってどれほど重要であるかに帰着します。

Lars Kemmann · Answer

デメリット

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

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

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

利点

多くの場合、SPAの主なアーキテクチャ上の利点（めったに言及されません）は、アプリの「チャティネス」が大幅に減少することです。クライアント上でほとんどの処理を処理するように適切に設計すれば（結局のところ、全体的に）、サーバーへの要求数（「ユーザーエクスペリエンスを破壊する503エラーの可能性」を読む）は劇的に減少します。実際、SPAは完全にオフラインの処理を行うことを可能にします。これは状況によっては巨大です。
クライアント側のレンダリングを正しく行えば、パフォーマンスは確かに向上しますが、これがSPAを構築する最も説得力のある理由ではありません。（結局、ネットワーク速度は向上しています。）これだけでSPAを採用しないでください。
あなたのUIデザインの柔軟性は、おそらく私が見つけたもう一つの大きな利点です。 APIを（JavaScriptのSDKを使用して）定義すると、静的リソースファイルを除き、フロントエンドをサーバーへのゼロの影響で完全に書き換えることができました。伝統的なMVCアプリでそれをやってみてください！ :)（これは、心配する必要があるライブデプロイとAPIのバージョンの整合性がある場合に役立ちます。）

要するに、オフライン処理が必要な場合（または少なくともクライアントが不定期にサーバーを停止しても耐えることができるようにする必要がある場合）は、ハードウェアのコストを大幅に削減します。それ以外の場合は、トレードオフの関係にあります。

Illidan · Answer

SPA - SEOの一つの大きな欠点。 GoogleとBingがクロール中にJavaScriptを実行してAjaxベースのページのインデックスを作成し始めたのはごく最近のことですが、それでも多くの場合、ページのインデックスが誤っています。

SPAの開発中は、おそらくすべてのサイトをポストレンダリングし、クローラ用に静的なHTMLスナップショットを作成することによって、SEOの問題に対処することを余儀なくされます。これには適切なインフラへの強固な投資が必要です。

更新19.06.16：

少し前にこの答えを書いて以来、私はSingle Page Apps（すなわちAngularJS 1.x）についてもっと多くの経験を積む - それで私はもっと多くの情報を共有する。

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

Greg Gum · Answer

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

しかし、あなたのページが主に表示用のものであれば、例えば利用規約ページであれば、SPAは完全に行き過ぎです。

特定のページにもよりますが、スウィートスポットにはSPAと静的/ MVCスタイルの両方のページが混在するサイトがあると思います。

たとえば、私が構築している1つのサイトで、ユーザーは標準のMVCインデックスページにアクセスします。しかし、その後実際のアプリケーションにアクセスすると、SPAが呼び出されます。もう1つの利点は、SPAのロード時間がホームページではなくアプリページにあることです。ホームページにロード時間があることは、初めてのサイトユーザにとっては気を散らすことになるかもしれません。

このシナリオは、Flashを使用するのと少し似ています。数年の経験を経て、Flash専用サイトの数は負荷率のためにゼロ近くまで低下しました。しかし、ページコンポーネントとしてはまだ使用されています。

Valentin Heinitz · Answer

Google、Amazonなど、24時間365日体制でサーバーが最大容量で稼働している企業にとって、トラフィックの削減は実質的なコストの削減、つまりハードウェアの削減、エネルギーの削減、メンテナンスの削減をもたらします。サーバからクライアントへのCPU使用率のシフトは効果が上がり、SPAが光ります。利点は、圧倒的に不利な点があります。したがって、SPAであるかどうかはユースケースに大きく依存します。

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

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

そのようなアーキテクチャに対して、SPAは多くの利点を提供します。デスクトップアプリ開発者にとってより身近な開発アプローチ、サーバーアクセスの減少（自動車業界ではUIとシステムの混乱は別々のハードウェアで、システム部分はRT OSを持ちます）。

唯一のクライアントはビルトインブラウザなので、JSの可用性、サーバーサイドのログ、セキュリティのような前述の不利な点はもう重要ではありません。

dam_js · Answer

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

私はまだたくさん学ぶ必要がありますが、私はSPAについて学び始めたので、私はそれらが大好きです。

この点は大きな違いを生むかもしれません。

SPAではない多くのWebアプリケーションでは、Ajaxリクエストを行うページにコンテンツを取得して追加することがわかります。それで、SPAはそれを超えることでそれを超えると思います：もしajaxを使って検索され表示されることになっているコンテンツがページ全体であるならどうでしょうか？ページのごく一部ではありませんか。

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

製品リストのあるページ
特定の製品の詳細を表示するページ

あなたがリストページにいると考えてください。次に製品をクリックして詳細を表示します。クライアントサイドアプリは2つのAjaxリクエストをトリガーします。

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

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

それからあなたはリストに戻り（これに対する要求はされません！）そしてあなたは別の製品を開きます。今回は、製品の詳細を取得するためのajaxリクエストのみがあります。 htmlテンプレートは同じものになるので、もう一度ダウンロードする必要はありません。

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

また、サーバーサイドの言語がJavaだとしましょう。前述の2つの要求を分析すると、1つはデータをダウンロードし（ビューファイルをロードしてビューレンダリングエンジンを呼び出す必要はありません）、他のダウンロードと静的htmlテンプレートを取得します。 Javaアプリケーションサーバーを呼び出さずに直接計算しても、計算は行われません。

最後に、大企業は、Facebook、GMail、AmazonのSPAを使用しています。彼らは遊んでいない、彼らはこれらすべてを研究している最高のエンジニアを持っている。それであなたが利点を見ないならば、あなたは最初にそれらを信頼することができて、道を進んで発見することを望みます。

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

JOP · Answer

私の開発では、SPAを使用することに2つの明確な利点がありました。それは私が追加の不利益を導入せずに増分の利益を見ているということだけで次のことが伝統的なWebアプリケーションで達成することができないということではありません。

新しいコンテンツをレンダリングするときにサーバー要求が少なくなる可能性があるとは限りませんし、新しいHTMLページをhttpサーバーが要求することもありません。しかし、新しいコンテンツではデータを取り込むためにAjax呼び出しが簡単に必要になる可能性がありますが、そのデータはそれ自体よりも徐々に軽量化され、最終的な利益がもたらされる可能性があります。
「州」を維持する能力。最も簡単に言うと、アプリへの入力時に変数を設定すると、それを渡したり、ローカルの保存パターンに設定したりすることなく、ユーザーエクスペリエンスを通じて他のコンポーネントで使用できるようになります。ただし、この機能をインテリジェントに管理することは、最上位のスコープを整理するための鍵となります。

私は、JSを要求すること（Webアプリケーションを要求するのは厄介なことではありません）以外にも、SPAに特有のものではないか、良い習慣や開発パターンによって軽減できるかどうかを指摘します。

Vish · Answer

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

a）セキュリティ：クロスサイトスクリプティング（XSS）のため、シングルページアプリケーションは従来のページに比べて安全性が低くなります。
b）メモリリーク：JavaScriptのメモリリークは強力なコンピュータの動作を遅くさせる可能性さえあります。従来のWebサイトではページ間の移動が推奨されているため、前のページによって発生したメモリリークはほとんど解消され、残されることはほとんどありません。
c）クライアントはJavaScriptを有効にしてSPAを実行する必要がありますが、マルチページアプリケーションではJavaScriptを完全に回避することができます。
d）SPAが最適なサイズになると、待ち時間が長くなります。例：遅い接続でGmailに取り組んでいる。

上記とは別に、他のアーキテクチャ上の制限は、ナビゲーションデータの損失、ブラウザでのナビゲーション履歴のログなし、Seleniumによる自動機能テストの難しさです。

このリンクはシングルページアプリケーションの長所と短所を説明します。

Bill Lawrence · Answer

サーバー側でセキュリティとAPIの安定性に対処する方法を最初に定義せずにSPAの使用を検討しないでください。それからあなたはSPAを使用することへの本当の利点のいくつかを見るでしょう。具体的には、セキュリティのためにOAUTH 2.0を実装するRESTfulサーバーを使用すると、開発コストとメンテナンスコストを削減できる2つの根本的な懸念の分離が達成されます。

これにより、セッション（およびそのセキュリティ）がSPAに移行し、サーバーがそのオーバーヘッドから解放されます。
あなたのAPIは安定していると同時に容易に拡張可能になります。

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

magnus · Answer

私はこれがより古い質問であることを理解しています、しかし私はシングルページアプリケーションのもう一つの欠点を加えたいと思います：

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