イマドキのWebシステムに向けて

 最近のWebシステムは、クライアント依存しづらくしなきゃだめよねー、ということで、サーバサイドにはJava、クライアントはJSON+JavaScriptレンダリングという構成でシステム構築を考えております。そんな中で気づいた事をメモっとこうかなぁ、と。

なんでそんな構成にするの?

 PCのWebブラウザだけでなくスマフォのブラウザやネィティブなアプリに対応しやすくするためです。サーバサイド処理を変えることなくクライアント側の処理で対応させちゃおうということです。サーバサイドの処理はJavaでなくてもPHPRubyでもなんでも良いわけです。クライアント側と会話さえできれば。

サクサク感がたまらない

 今まではsubmitして画面表示しなおすという方式が当たり前だったのですが、この方式に慣れてしまうと、画面遷移がモサく感じます。何か、ボタンを押すたびに画面が切り替わってスクロールバーが一番上に戻ることに違和感を持つようになりました。
 そして、レスポンスには、必要な情報だけ返せば良いというのが気に入っています。ある部分だけ書き換えたいのに他の余計な情報まで意識してレスポンスに含めないといけなかったあの頃の俺、どうかしてるぜ、的なノリです。何ていうんでしょうか、検索条件を受け取り、検索結果を返す処理なのに、レスポンスには検索条件も含めなければならない違和感。それが無くなり、必要な情報だけ返せば良くなった、というのは処理の見通しも良くなる、ということです。


ハマらない為の工夫

処理の分散を防ぐ

 jsで判断文を書くとロジックがサーバ側とクライアント側に分散する可能性があるので、できるだけサーバサイドに処理を押し込んでjsではレンダリングに徹してもらうのが良いのではないか、と思います。どうせJSPでその辺の処理を書いていたわけですからサーバの負荷はそんなに大きくなるわけじゃないと思いますし。

サーバとの通信

 同期させてます*1。非同期にすると同期が必要な時にいろいろ制御しなきゃいけなくなりそうでしたから。同期しておけばその辺を考えなくて済みますし。全画面描画しなおすのが嫌なだけです。

なるべく状態を持たないように

 jQueryjQueryプラグイン等を使っているのですが、ソースコードを隅々まで見ているわけではないのであまりわかってませんけど、js側で「状態」を持ってしまい、それが不整合を引き起こすことが怖いので、サブメニュー単位では画面を再描画させるようにしてjsの状態を持ち続けないようにクリアしています。変数の有効範囲を狭くすることで変な所でつまづかないようにしてます。

クロスブラウザ対応

 ブラウザによる処理の違いがあります。特ににInternet Expl○rerって奴は困ったものなのですが、それでもjQueryさんとかや作り自体を変えることで対応できてます。まぁ、クロスブラウザ対応を謳ってしまえばこの構成でなくても逃げられないと思うんですけど。システムは作って終わりじゃないということで根本的な解決策は見つかってません。

まとめ

 ここまでjsに依存したWebアプリには抵抗感があったのですが、今回をきっかけに「悪くない」と思うようになりました。ビバ、js。
 サーバサイド側の処理は、JSPへの依存が薄くなった分、さらにロジックの記述に集中できるので、テストしやすくなるってもんです*2
 後は、デザインセンスが圧倒的に不足しているのが露呈されます。あぁ、俺はロジックを書くことしかできないんだな、って。いや、僕だけの問題なんですけど。「業務システムなんだから見栄えなんて二の次」なんて自分を慰めてますけどオサレなものにしたい欲求が抑えられません。デザインの本買おう。

*1:厳密にはAjaxではないんです

*2:ですが、「M」「C」と「V」の分業ができてるプロジェクトが一体どれほどあることか・・・