1. ホーム
  2. ジャバスクリプト

[解決済み】シングルページアプリケーション:メリットとデメリット【終了しました

2022-04-11 01:58:27

質問

SPAとその利点について読んだことがあります。私はそのほとんどに説得力がないと感じています。3つの利点は、私の疑念を呼び起こすものです。

質問です。 あなたはSPAの擁護者として、私が最初の3つの発言について間違っていることを証明することができますか?

                              === ADVANTAGES ===

1. SPAは非常にレスポンスの良いサイトには非常に適しています。

<ブロッククオート

サーバーサイドレンダリングは、すべての中間的な 小さなビューの状態は、URLとうまく対応しません。

シングルページアプリは、どの部分でも再描画できることが特徴です。 を取得するためのサーバーラウンドトリップを必要としません。これは データ表示とデータを切り離すことで、この機能を実現しています。 データを扱うモデル層と、データを読み込むビュー層があります。 をモデルから読み取る。

非SPAでモデル層を持つことの何が問題なのでしょうか?クライアント側でMVCと互換性のあるアーキテクチャはSPAだけなのでしょうか?

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

はて、あなたのサイトを訪れたユーザーがダウンロードできるページ数はいくつでしょうか?2つ、3つ?それどころか、別のセキュリティ問題が出てきて、ログインページや管理ページなどを別のページに分ける必要があります。そして、それはSPAのアーキテクチャと矛盾します。

3.他に利点はありますか?他にはないのですか?

                            === DISADVANTAGES ===

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

P.S. 私はSPAと非SPAのプロジェクトに携わったことがあります。そして、理解を深める必要があるので、このような質問をしているのです。SPAサポーターを傷つけるつもりはありません。SPAについてもうちょっと読めなんて言わないでください。ただ、それについての考察を聞きたいだけなのです。

解決方法は?

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

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

サーバーサイドレンダリングは、URLに#hashを保持するような簡単なテクニックで、以前ほど難しくなく、最近では HTML5 pushState . このアプローチでは、ウェブアプリの正確な状態がページのURLに埋め込まれます。GMailのように、メールを開くたびに、特別なハッシュタグがURLに追加されます。コピーして他のブラウザに貼り付けると、まったく同じメールを開くことができます(認証が必要な場合)。この方法は、より伝統的なクエリー文字列に直接対応し、違いは単にその実行にあります。 HTML5のpushState()を使用すると、URLの前にある #hash 最初のリクエストではサーバーで解決し、その後のリクエストではajax経由で読み込むことができる、完全に古典的なURLを使用します。

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

私のウェブサイトを訪れたユーザーがダウンロードするページの数?もし、サーバーサイドレンダリング方式を採用するのであれば、サーバーはリクエストごとにレンダリングすることになります(典型的なケースです)。 - セキュリティの懸念 - 管理者/ログイン用に別々のページを維持するべきかどうかは、サイトの構造に完全に依存します。例えばpaytm.comを例にとると、WebサイトをSPA化しても、すべてのユーザーに対してすべてのエンドポイントを開放するわけではありません。 - おそらく最も使われているSPAフレームワークであるAngular JSでは、開発者がWebサイトからhtmlテンプル全体をロードすることができるので、ユーザーの認証レベルに応じて行うことができます。

3. 他に利点はありますか?他に聞いたことがないのですが。

  • 最近では、クライアントがJavascriptを有効にしたブラウザを使用していると考えて差し支えないでしょう。
  • サイトの入口は1つだけです。先ほど述べたように、状態の維持は可能なので、入口はいくつあってもいいのですが、確実に1つにしておくべきです。
  • SPAでも、ユーザーは適切な権限を持っているものしか見ることができません。一度にすべてのものを注入する必要はありません。

思いつくメリットは

  1. また、レンダリングだけでなく、主要なロジックはサーバーサイドからクライアントサイドで行われるようになりました。
  2. 日付と時刻の問題 - UTC時刻をあらかじめ設定したフォーマットでクライアントに渡すだけで、タイムゾーンは気にせず、JavaScriptに処理させることができます。
  3. クライアントサイドの状態を使用しない場合、高価なセッションを使用することになるので、これはfoodpanda、flipkart、amazonのようなサイトを作る際に非常に役に立ちます。
  4. 極端な例として、SPAでないWebサイトで電卓を作ってみましょう(変な話ですが)。

コメントからの更新情報

<ブロッククオート

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

別の視点から。ウェブサイトはもちろんのこと、プロジェクトは ネイティブ・モバイル・アプリケーションを含むか?もしそうなら、ほとんどの場合、次のようなことが考えられます。 サーバーからネイティブアプリに生データを送り(つまりJSON)、そのデータを使って クライアントサイドの処理でレンダリングするんですよね?つまり、この主張では クライアントサイドのレンダリングモデルをすでに行っていることになります。そこで問題なのは 同じモデルをWebサイト版にも使ったらどうでしょう。 を作成しました。当然といえば当然ですね。次に問題になるのは サーバーサイドのページをレンダリングするのは、SEO対策と 共有・ブックマーク可能なURLの利便性