ウェブ開発の「古典的な」アプローチは、しばらくの間、シン クライアントとシック サーバーでした。サーバーは HTML を生成し、それをブラウザーに出力してレンダリングするだけです。しかし、現在のブラウザーでは (また、優れたライブラリとフレームワークが利用できるため)、Javascript が機能するようになりました。ウェブ開発者は、Javascript コードが機能することをほぼ前提として、煩わされることがなくなりました。
これは確かに Web 開発に新たな可能性を開きました。アプリは、サーバーから返され、クライアント側で UI 操作を行ってブラウザーでレンダリングされる HTML コンテンツで大部分を構成することができるようになりました。クライアントは、UI の一部を更新するためにサーバーに最新のデータを問い合わせることさえできます。しかし、まったく逆の方向に進むことはできるでしょうか? アプリは、ユーザー インターフェイス全体の構築と制御を担当する強力な JavaScript クライアントに接着された最小限の JSON のみを吐き出すサーバーとして設計できます。確かに、このアプローチでは URL が深刻に壊れてポインターを送信できなくなる可能性がありますが、それを回避する方法を設計することは確かに可能です (電子メールやフィード リーダーなどの一部のアプリでは、これは問題になりません)。
どう思いますか？そのアプローチを試したことがありますか？動作が遅くなりすぎますか？最新のブラウザは、その量のJavascriptコードを処理できますか？最新のライブラリを使用しても、アドバイスを受けていない開発者にとって依然として問題となるブラウザ実装間の大きな違いはありますか？このアプローチはどのような種類のアプリケーションに適していると思いますか？実際に適していますか？何でも?
ベストアンサー1
私はまさにこの種のアプリの構築を最終段階に進めています。これは、Zend Framework JSON-RPC Web サービス上に構築された ExtJS GUI で、iGoogle のようなガジェット ポータルを実装しています。
利点:
- 非常に応答性の高い UI である ExtJS は、優れたユーザー エクスペリエンスを提供します。
- 非常に予測可能なクライアント サーバー通信。すべてが JSON なのでデバッグが簡単。API には標準化されたエラー処理が組み込まれています (少なくとも私はそのように設計しました)。
- フロントエンドは交換可能です。同じサーバー バックエンド上に C++ アプリを作成できます。クライアントとサーバーのラインを越えてフロントエンドとバックエンドを分離すると、個別にテストしやすくなります。
- JavaScript に没頭できるようになり、それが好きなら素晴らしいことです。
デメリット:
- JavaScript に生き、JavaScript を呼吸しなければなりませんが、それが嫌いなら最悪です。私たちの場合、PHP を多用していたため、これは開発者チームの大幅な再トレーニングを意味しました。
- すべてが単一の長寿命 DOM 内に存在するため、メモリ管理を常に意識し、適切にクリーンアップされていることを確認する必要があります。また、UI をロードしすぎると、IE が「痛い、痛い、頭が痛い」という状態になります。
- UI の生成中に、オプションを取得するためにクイック クエリを実行することはできません。クライアント上で実行されるプログラム設計の制約は、最初は気が遠くなるものです。慣れれば問題ありませんが、少しハードルが高くなります。
- すべての JavaScript をロードするには、ユーザーは高速接続と最新のブラウザを使用する必要があります。
これを実行する主な理由は、より優れたユーザー エクスペリエンスを提供することです。ユーザーはデスクトップのようなエクスペリエンスを期待していますが、サーバー間の往復ではそれを実現できません。現在ではそれを実現していますが、このようなアプローチには大きな課題があることは否定できません。とはいえ、全体的には満足しています。
更新（2013年9月）：
このアーキテクチャを今でも使用しており、本物の Web アプリケーション (動的な機能を備えた Web ページだけではない) を構築する場合は、これが適切なアーキテクチャだと考えています。私たちのチームと製品は現在、はるかに大きくなっています (コード行数は 500,000 行近く) が、アーキテクチャは問題なく拡張されています。現在では、非常に優れたスケーラブルな JavaScript フレームワーク (Angular、Ember など) が多数あるため、この作業方法を採用するのはこれまで以上に簡単です。
@rwoo が尋ねたところによると、まだ残っている課題がいくつかあります:
- オンデマンドでの js コードの読み込みは、予想以上に難しい問題であることが判明しました。アーキテクチャ内でこの部分を正しく理解することが重要です。
- js は構文エラーに対して非常に寛容であり、製品が顧客に届くまでこれに気付かないことが多いため、Subversion のコミット前フックに自動 jshint 検証を統合する必要がありました。
- データベースは Web サービス リクエストの反対側にあるため、Web サービス API を慎重に設計する必要があります。そうしないと、XHR リクエストを待ちすぎることになり、パフォーマンスが低下します。これは解決可能ですが、困難であり、時間が経っても簡単になりません。
- 適切なフレームワークを使用すれば、クロスブラウザの問題は最小限に抑えられますが、完全になくなるわけではないため、すべてのブラウザ、すべてのバージョンでテストする必要があります。これは非常に手間がかかる作業であるため、Selenium などを使用して自動化する必要がありますが、クライアント側でレンダリングされた UI では、サーバー側でレンダリングされた UI よりも実行が困難であることが判明しています。