クライアントサイドにReact.jsやAngular.jsを使い、サーバーサイドでDjangoを用いたWebアプリケーションって、どういう仕組みなのか気になっていたが、調べてみて、少しずつ理解していった。
参考
①勉強会JS編＜2＞ クライアントサイドMVCフレームワーク
"アプリケーションの変遷"という項目がスッキリさせてくれた。
- スタンドアロンアプリケーション
- Webアプリケーションではなく、スタンドアロン環境で動くGUIアプリケーション。
- クライアント・サーバ方式（多数のスタンドアロンアプリケーションがDBサーバとSQLで通信）
- シンプルWebアプリケーション
- サーバ側でのプログラミングを中心にしたWebアプリケーション
- 画面遷移とGUIの状態を一致させることで、状態を意識しないプログラム実行環境が実現
- HTMLのGUI部品により、表現力や操作性はスタンドアロンアプリケーションに比べて低下したが、アプリケーション開発の生産性は大きく向上
- リッチWebアプリケーション
- リッチなGUIを持つWebアプリケーション
- 画面遷移はほとんどない。
- 裏でサーバと通信する必要があるデータだけリアルタイムでやりとりしたり、リッチなモーダルダイアログを表示する。
- GUI制御のプログラムをJavaScriptで書く必要がある。
Backbone.js の機能
- Key-Value型のデータとカスタムイベントを持つモデル
- 複数のモデルをリスト化し、リストを操作するAPIが整ったコレクション
- HTMLの描画とイベントハンドリングを担当するビュー
- サーバとJSON（JavaScript Object Notation）をやりとりするRESTfulインタフェース
②クライアントサイドMVCを使ったときのサーバサイドの役割
サーバーの役割の変化
HTMLを生成 → JSON APIを提供する
例えば Twitter API を使うと Twitter クライアントを作ることができますよね。iOS 用クライアント、Android 用クライアントなど様々なものがあって、そのなかのひとつとして HTML と JavaScript でできたクライアント (= twitter.com) がある、というようなイメージです。
とはいえ、すべてのドメインロジックがクライアントに移るわけでもありません。アクセス制御はもちろんとして、更新系で整合性を保つこと、クライアントの必要に応じた粒度でリソースをエクスポートすることなどはサーバサイドの責務です。データベースのレコードをそのままエクスポートするだけではこれらを実現できないので、サーバサイドでも MVC フレームワークを用いることは普通にありえることです。この場合、View は HTML の代わりに JSON を生成することになるでしょう。