妄想全快!!WebFramework
お腹イッパイ、夢イッパイ
太一
2007/07/28
本日のお題
「私が考える次世代Webアプリケーションフレームワーク」と言う事で
太一が最近考えているWebFrameworkについて妄想を全開するます。
誰が作るとか、いつ作るとか、そういう事は余り考えてません。
実現可能性についても、気合で何とかなるだろう程度にしか検証してません。
取り合えず、言いたい事を先にまとめると、
- クライアントサイド、もうちょい頑張れねぇの?
- 専用の開発ツール前提でしょうなぁ
- 専用のWebサーバも前提になりますなぁ
- 既存のF/Wとは全く違う観点のパフォーマンス向上施策を考えてみた!
- 既存のF/Wでは実現しえないセキュリティという名の嫌がらせをしたいなぁ
クライアントサイド偏重
JavaScriptによるクライアントサイドレンダリング。
そういえば、mopeさんが最近Teedaに何か追加してた様な…
AdobeのSpryってのもあったり。
でも、僕の妄想では、そういう事じゃない。
レイアウトを決めるテンプレート以外は、
完全に分割されてバラバラになった画面部品を、
クライアントサイドから非同期に送られるリクエストに
対するサーバの部分的なレスポンスを元にレンダリングする。
それを、あまり苦労せずにやれる様にしたらどうかしらん?と言う事。
携帯電話?プアなノートPC?WindowsMobile?知りません。
ハンドヘルドな彼らには、より最適化した何かを用意するべきです。
レイアウトの話
最初の画面は、こんな感じのHTML。
要はレイアウトを決める専用のHTML部品
<html><body>
<div a:id="frame">
<div a:id="menu"></div>
<div a:id="breadcrumbs"></div>
<div a:id="main"></div>
</div>
</body></html>
画面を構成する部品の話
それぞれに対して、クライアントが
非同期にサーバへリクエストを送信すると
サーバは、大体こんな感じの結果を返す。
それぞれが、全部違うリクエスト/レスポンスの組になる所がポイント。
<div a:part="main">
<div a:id="hoge"></div>
<div a:id="fuga"></div>
</div>
<div a:part="hoge">
<label>ホゲ</label><input type="text" a:id="firstInput" name="pe78Vcd" />
</div>
<div a:part="fuga">
<input type="button" a:id="button" name="ujg_47" value="${buttonvalue}"/>
</div>
条件分岐やループは、アイディアレス
条件分岐やループ、値の配置はクライアントサイドで行うのは必須。
これは、
Spry
<div spry:region="data">
<div spry:repeat="data">
<span>{data::name}は{data::price}円です。</span>
</div></div>
これは、
EJS
[% var title = "Items to buy!"; %]<h4>[%= title %]</h4>
<ul>
[% ['cupcake', 'hardware'].each(function(item) { %]
<li>[%= item %]</li>
[% }); %]
</ul>
代替案が無いんだけど、どっちのモデルもイマイチ…みたいな。
クライアントサイドレンダリングまとめ
要は、どんなにデカい画面でも、
細かいリクエスト→レスポンスの組合わせにする事で、
サーバ側を極端にスループット重視に出来ないかなぁ…と言う事。
只、既存の1コネクション1スレッドのモデルを持つサーバでは、
このモデルは、絶対にスケールしない為、非同期IOできるサーバが必要になる。
又、部品をより細かくする事で、静的なファイルを増やす事が可能になり、
キャッシュサーバを上手く使える様になる。
まぁ、最近の複数コアCPUを全開に使いたいじゃんって事。
後、SUNの
UltraSPARC T1(Niagara)みたいな偏ったアーキテクチャのCPUぶん回せるって凄くない?
リロード?戻るボタン?
URLのハッシュ化を使って、勝手なタイミングで、全体再描画を逐次行う。
イメージ的には、トランザクションのチェックポイント的な所で、
ハッシュ付URLをサーバに送信する。
例えば、こんな感じのURL。
http://uniuni.dfz.jp/sekai/swd.html?20Ixzsak1cBdA2l
ハッシュ化されたURLをサーバがリクエストされると、
そのハッシュから複合化したレンダリング情報をサーバ側はレスポンスする。
例えば、レイアウトを決めるテンプレートをクライアントサイドにレスポンスすると
クライアントサイドは、そこから描画に必要な情報を拾って、
再度サーバにリクエストをゴッソリ送る事になり
結果的に、ある程度の所までは、描画状態を復元する事が可能になる。
状態情報
んなもん、クライアントサイドで押さえとけ。
サーバ側に抱えるから、スケールしないんじゃん。
ハッシュ付URLの中に、状態情報のキーとなる情報を含めるのかなぁ…とか。
頻繁にデータが更新されない事を前提に、
サーバサイドでデータを永続化して、チェックポイント的なタイミングで、
クライアントサイドとサーバサイドのデータを同期する。
さすれば、入力に面倒な情報がガッサリ消えたりする事も無いでしょう。
逆にサーバと同期するタイミングが存在する事で、
クライアントサイドで悪さし辛くなる感じ?
開発環境
FirefoxのExtensionないし、IEのActiveXコントロールは必須で。
機能としては、
- WYSIWYG的な挙動をするエディタである事
- ばらばらに分割される部品を、それぞれストレス無く編集出来る事
- ばらばらに分割される部品を、ストレスなくドラッグ&ドロップで配置できる事
- ブラウザで書いた部品が、ストレス無くサーバに配置される事
- サーバと開発環境で、編集内容をリアルタイムに同期する事
- ループや条件分岐の為の局所的なデータは、ツールがテキトーに作ってくれる事
- 画面の作成中は、結果を確認する為に、サーバを停止させない事
セキュリティと言う名の嫌がらせについて
既存のWebFrameworkは、結局の所、固定化されたキー=バリュー形式から、
サーバサイドのモデルにマッピングしている。JSFは違う?そうでも無い様な…。
セキュリティ的には、レンダリングされる度に、キーの部分がどんどん変化する様にする事が望ましい。
その為に、サーバにデータを送信する際、恒常的に、チャレンジレスポンス的な動作をする。
サーバから逐次的に送信される1タイムトークンを使って、クライアントは、送信内容を暗号化する。
もしくは、その1タイムトークンを使ってレンダリングされるINPUTタグのname属性を暗号化する。
そうする事で、単一のTCPセッションをTCPモニタで監視しても、
送信内容を簡単には傍受出来なくなる。
サーバサイドのプログラミングモデルについて
資料作成中に失速してきた感があるので、エッセンスだけ。
- interfaceドリブンな型ガチガチの世界
- URLのパス構造と動作するオブジェクトがマッピングされる
- 画面遷移は、似非URLをぶん回すYmir的なアレ
- 開発時に苦労する事無く継続を使えないかなぁ…ポヮヮ
- サーバサイドで、状態情報は保持しない方向で
- 入力情報は、スーパーMapラッパーで取り出すか、開発ツールとサーバが連動する事で完全に自動生成される感じ。どちらにせよ人間様がDTOを作るようなマネはしない方向で
- DIコンテナ的なモノは、何らかの形で必要かと思うものの、再検証の価値あり
- 入力バリデーションは、JavaScriptで、クライアントとサーバが同じリソースを参照して行う。但し、サーバサイドは、JavaScriptを直接動作させずバリデーションのコードを自動生成する様なイメージ
オシマイ
現在、3時。何か他にも考えてた事がある気がするけど、
シンドイので、もう寝るマス。
と言う訳で、オシマイです。