単一ページのWebアプリケーションを構築する利点と欠点[非公開]

私は現在取り組んでいるサイドプロジェクトのプロトタイピング/概念実証フェーズの終わりに近づいており、いくつかの大規模なアプリケーション設計の決定を決定しようとしています。このアプリは、アジャイル開発プロセス向けに調整されたプロジェクト管理システムです。私が下す必要がある決定の1つは、従来のマルチページアプリケーションとシングルページアプリケーションのどちらを使用するかです。

現在、私のプロトタイプは従来の複数ページのセットアップですが、backbone.jsを見て、Javascript（jQuery）コードに構造をクリーンアップして適用しています。Backbone.jsは複数ページのアプリケーションで使用できますが、単一ページのアプリケーションでさらに輝いているようです。単一ページのアプリケーション設計アプローチを使用することの利点と欠点のリストを考えています。これまでのところ：

長所

• すべてのデータは何らかのAPIを介して利用できる必要があります。これは、アプリケーションにAPIを保持したいので、ユースケースにとって大きな利点です。現在、データの取得/更新の呼び出しの約60〜70％がREST APIを介して行われています。単一ページのアプリケーションを実行すると、アプリケーション自体がREST APIを使用するため、REST APIをより適切にテストできます。また、アプリケーションが成長するにつれて、API自体も成長することを意味します。これはアプリケーションが使用するものだからです。APIをアプリケーションのアドオンとして維持する必要はありません。

• より応答性の高いアプリケーション-最初のページの後に読み込まれるすべてのデータは最小限に抑えられ、コンパクトな形式（JSONなど）で送信されるため、データ要求は一般に高速であり、サーバーの処理はわずかに少なくなります。

短所

• コードの複製-たとえば、モデルコード。サーバー側（この場合はPHP）とJavascriptのクライアント側の両方でモデルを作成する必要があります。
• Javascriptのビジネスロジック-これが悪い理由について具体的な例を挙げることはできませんが、だれでも読むことができるJavascriptのビジネスロジックを持っていると感じることはできません。
• Javascriptのメモリリーク-ページがリロードされないため、Javascriptのメモリリークが発生する可能性があり、デバッグをどこから開始すればよいかさえわかりません。

また、両刃の剣のようなものもあります。たとえば、単一ページのアプリケーションでは、アプリケーションが特定の要求に必要な最小限のデータを要求するため、各要求で処理されるデータは大幅に少なくなりますが、サーバー。それが良いことなのか悪いことなのかはわかりません。

単一ページWebアプリケーションの長所と短所のうち、プロジェクトにどの方向に進むべきかを決定するときに留意すべきことは何ですか？

最大の欠点は、クライアントでJavaScriptを有効にし、かなりの量のJavaScriptを実行できるほど強力でなければならないことです。また、アクセシビリティの問題や、静的HTMLの解析に依存するその他の問題に対処することは困難です（ただし、特定のAPIを知っていると、HTMLスクレイピングよりも優れている可能性があります）。最後に、重大なメモリリークが発生しやすくなります。

コードを複製したり、クライアントにビジネスロジックを配置したりすることに関しては、どれだけの作業が必要かわかりません。クライアント上のモデルがView-Model（UIがビジネスモデルではなく世界と一致するモデル）である場合、ViewModelをビジネスモデルに一致させるロジックはクライアントに常駐できます。サーバー、または両方のビット。APIにクライアント固有のファサードを含めることと、クライアントがUI入力をAPI呼び出しに変換することをどのように感じるかによって異なります。

knockout.jsもご覧ください。バックボーンよりも優れているかどうかは言えませんが、プロジェクトにより適している可能性があります。

単一ページWebアプリケーションでよく見られる欠点：

• サイトの特定の部分にリンクできない場合、多くの場合、エントリポイントは1つだけです。
• 機能しない戻るボタンと進むボタン。
• タブの使用は制限されているか、存在しません。

（特にモバイル:)

• ロードに非常に時間がかかります。
• まったく機能しません。
• ページをリロードできません。ネットワークが突然失われると、サイトの最初に戻ります。

これらはすべて回避できますが、私が見たところから、ほとんどのサイトビルダーはそうではありません。

Javascriptを実行しない重要なクライアントが1つあります。Googleクローラー（2012年現在）です。（BingもJSを実行しません、と思います。）

インデックスを作成する必要があるすべてのページの合理的な非AJAXバージョン、またはインデックスを作成する必要があるページへのリンクを提供する必要があります。

サイトが小さい場合、ボットのインデックス作成のためだけに、いくつかのページの非常に基本的なバージョンを提供できます。

サイトのコンテンツのほとんどが登録ユーザー専用である場合、または他の何らかの理由でインデックスを作成する必要がない場合、独自の検索、ブラックジャックなどを使用して、インデックスなしのスペース全体を1ページアプリとして作成できます。

これらのどちらでもない場合は、最初からマルチページサイトを開発し、ページの「汎用」を変更しないAJAX更新のみを提供する方が良いでしょう。

-コードの複製-たとえば、モデルコード。サーバー側（この場合はPHP）とjavascriptのサーバー側の両方でモデルを作成する必要があります。

あなたはPHPの世界にいますが、.NETの世界にはJavaScript WCFプロキシを自動的に作成するためのコード生成戦略があります。こちらをご覧ください

PHPアプリケーションのJavaScriptでリモートオブジェクトを自分で作成する必要がないオプションがどのように利用できるかわかりませんが、これは.NETで単一ページアプリケーションを作成するためのオプションです。

選択はどちらかである必要はありません。たとえば、JWtは、複数ページのWebページの完全な錯覚を実装するWebツールキットですが、単一のページです。さらに、JavaScriptを持たないgoogleボットとブラウザを認識し（試用）、それらを検出すると従来のマルチページモデルに切り替えます。

要するに：

• APIを記述する必要はありません（ただし、必要な場合は引き続き可能です）
• レスポンシブアプリケーション：ユーザーのクリックごとに、最大1つのサーバーラウンドトリップ（および画像の取得）が必要
• コードの重複なし
• クライアント側のビジネスロジックなし
• 最小の複雑さのクライアント側
• 検索ボットはインデックスを作成できます