「分離された」Webアプリケーションの利点/欠点
私は（間もなく）かなり大きなPHP/MySQL Webアプリケーションを設計しています。内部アーキテクチャに関しては、私は道に分岐しました。 Webサイトを「従来の」Webアプリケーションとして構築できます。リクエストを行うと、サーバーがHTMLページを構築し、ページ全体を送信し、ブラウザがレンダリングします。または、「分離」最初のロード時にHTML構造とアプリケーションのコード全体がブラウザに提供され、アプリケーションはJavaScriptコールバックを使用して、統一されたAPIを介して特定のデータを取得したりコマンドを発行したりするWebアプリケーション。また、サイトには複数のバージョン（デスクトップ、モバイル、iPhone/Androidモバイル、検索エンジン対応など）があり、ある時点で、おそらくスタンドアロンのモバイルアプリやデスクトップアプリも存在する予定です。
Web開発者として、これらの各アーキテクチャでどのような利点/欠点がありますか？私が一方を他方の上に行くべき明確な理由はありますか？それは開発者の好みのものですか？
まず、非同期の重いWebサイトを利用するかどうかは、iPhone /モバイルアプリやデスクトップアプリとは関係ないため、iPhone /モバイルアプリやデスクトップアプリを構築する能力に大きな影響を与えません。いずれにしても、コードを再利用することはできません。
また、非同期サイトは通常のサイトと同じかそれより遅い場合があります。通常、この種の機能は、特にユーザーエクスペリエンスの向上のために追加されます。 JavaScriptを使用すると、WebクローラーがJavaScriptの意図を完全に理解できず、ほとんど無視するため、SEOであなたを傷つける傾向があります。
あなたが探しているのは、機能（中間）層を一度だけ記述し、すべてのアプリに同じものを使用することにより、開発オーバーヘッドを削減する方法だと思います。この場合、私は価値があると思いますが、率直に言って、これらの種類のアーキテクチャはセットアップが難しく、多くの時間がかかります。私はあなたがあなたのウェブサイトをあなたができる限りベストに開発し、あなたの中間層コードをあなたができる限り強く保つべきだと思うでしょう。そうすれば、iPhoneアプリを追加するときや、共通の中間レベルのモデルに簡単に移動できるものを追加するときに
ここで私が本当に主張しているのは、赤ちゃんの一歩を踏み出すことです。まだ知らないことを処理するために、今すぐコードを書こうとしないでください。必要なコードを記述して、できるだけ柔軟にします。
JavaScript/AJAXに大きく依存している「分離された」アプリケーションのアイデアは、多くのトラブルに巻き込まれると思います。私の頭の上のいくつかのこと：
- Googleは何かをインデックス化するのに苦労するので、SEOにとっては悪いことになるでしょう。
- それを「ブックマーク可能」にするのは難しいだろう
- モバイルデバイスの多くはJavaScriptのサポートが非常に限られている（または壊れている）ため、モバイルデバイスには苦労します。
第一に、この答えがあまりにも明白または基本的である場合、違反はありません。 AjaxやjQueryなどの用語の代わりに「分離された」を使用すると、このトピックの経験が少なくなります。もちろん、質問を読み間違えている可能性がありますので、その場合はおologiesび申し上げます。
両方を使用するが、賢明に
タスクが最も効率的に行われる場所と方法の観点から、サーバー側またはクライアント側のタスクの選択を考えてください。これにより、ページを（サーバー上で）すばやくレンダリングできますが、ブラウザーに処理をオフロードするのが理にかなっています。そして、判断の電話をかける必要がある灰色の領域があります。 あなたの仕事は賢い分業を見つけることです。
サーバー側に属するものは何ですか？
（これは要点を説明するための極端な例です。）何らかのタイプの検索を行うWebアプリを書いているとします。ブラウザ側のJavascriptを作成してサーバー側のPHP Webサービスを呼び出して2GBデータベース全体を取得し、「サーバーを解放」して検索をユーザーのマシンにオフロードしません。行うことは、フォームからユーザーから検索用語を取得し、POSTそれをサーバーに戻してデータベースに直接照会し、結果をサーバーからブラウザーに送り返すことです。
ここでのロジックは、DB自体がクエリの最適な実行方法を認識しており、サーバーがソースデータに近く、コンポーネント間で移動する必要のあるデータが少ないことです。ブラウザは表示するものだけを必要とするので、すべてをブラウザに送信しないでください。 （相対的な言語パフォーマンスは言うまでもありません。）
ブラウザには何が属しますか？
ブラウザ側のコードは「分離された」シナリオです（正しく理解している場合）。しかし、ブラウザがインテリジェントな機能を実行するには、サーバーの協力が必要です。
さて、あなたはあなたの検索アプリを動作させましたが、あなたはいくつかの派手なパンツAjaxでそれを飾り付けたいです。 PHP Webサービスを作成して、数文字を取得し、一致する検索語を返しますa laBingの「検索候補」機能、Googleなど。ユーザーが3文字または4文字で入力した後にのみ用語を提案するようにブラウザーコードを記述するため、候補リストは小さくなります。サーバーに戻って、そのフィールドでデータベースのインデックスを作成し、検索が高速で高速になるようにします。
ここでの考え方は、「検索候補」はmustがサーバーとクライアントに分割される機能であるということです。ブラウザーは、ターゲットの小さなデータの山をすばやく処理できます。サーバーは、ターゲットを絞った小規模なデータの山を取得し、それをクライアントに提供できます。貧弱な区分では、サーバーが可能なフィールド値のモンスターリスト（たとえば、500,000アイテム）をHTMLページに埋め込まれたXMLアイランドとしてレンダリングし、ユーザーが入力するときにブラウザーで検索します。 （a）すべてのデータをブラウザに送信するのが遅い、（b）Javascriptで検索するのはneverDBに検索させるのと同じくらい速く、 （c）すべてのデータをブラウザアプリのスペースに詰め込んで、ユーザーのマシンを爆破する可能性があります。一方、Ajaxがサーバーを呼び出し、その後のクエリとリターンが超高速であることをsureにする必要があります。のんびりダディはありません。
灰色の領域はどこですか？
ここでもまた、それは判断の呼びかけです。上記では、サーバーが検索を実行し、結果をブラウザーに送信することについて説明しました。しかし、疑問が生じます。ブラウザにフォームを使用して検索語を送信させ、サーバーに結果ページをレンダリングさせますか、またはクライアント側のAjax/Javascriptを使用して検索語を送信し、結果を取得してからレンダリングしますか？ DIVでページの更新を回避しますか？両方とも有効です。リソースの面では、どちらの方法にも本当の利点はありません。 Ajaxの方法は、より良いユーザーエクスペリエンスを提供できますが、アプリや状況によっては、その他の課題（セキュリティなど）が発生する場合があります。
ボトムライン
両方を適切に使用してください。アーキテクチャのパフォーマンスと効率性について考えたり、学習したりしないでください。より少ないデータ、より少ない回数で移動します。サーバー、データベース、およびユーザーのブラウザーの負荷を軽減します。
コードを再利用できるようにするために、ランディングページの生成のために常にXSLTを確認し、AJAXのXML/JSONインターフェースを使用できます（XSLTランディングページのXMLインターフェースを使用）。
通常、コンテンツとインタラクションが/ json/...および/ xml/...プレフィックスを持つRESTfulインターフェイスで動作し、メインコンテンツをホストし、/ ...のXSLTを介してマークアップに変換されるようにします。
このようにして、人々はどのページにもアクセスでき、突然AJAX Webサイトを完全に開くことができます。クモはあなたのサイトをクロールでき、あなたは何よりもまずコンテンツ/インターフェースに集中しました-勝ち勝ちのようです。
モバイルWebサイトでは、異なるレイアウトが必要になる場合があります（iPhone専用のサイトはありますか？）さまざまなユーザークライアント向けの単純なXSLT変換は、これまでに行ったすべてを再利用できます。
単純なHTML出力とナビゲーション用に設計することを忘れないでください。AJAXの簡略化は従うことができます。
PS-XSLT変換サーバー側を実行