これからのアプリ開発について考えている。
「アプリ」というと、Webアプリ/iPhoneアプリ/Androidアプリ/iPadアプリ ・・・ ときりがないくらい出てくる。
最近はAndroidアプリを開発している。
そんな時、それぞれ一個ずつ対応する必要があるわけだが、サーバ側で担う部分としては全て共通で利用できるようにしたい。 そう考えると従来のWebアプリケーションフレームワークでは、コントローラの部分にViewを扱うためのデータ整形などの処理が入るため、どうしてもWebのHTML用、スマホ用とか分けないといけない場面が多いと感じている。
もうサーバ側でHTMLを作っていくスタイルとはおさらばせねば。
これからはクライアント側でAPIを元に作っていくのが主流になる（はず）。
そういう意味で、「WebAPI」の考えはこれからめちゃめちゃ大事になる。全ての環境で共通に使えるAPIだ。
さて、そう考えるとWebアプリの立ち位置はどうなるだろう？従来のWebフレームワークの考えかを捨て、API用のWebサーバを作ることになる。APIだけであればRailsのようないろんな機能を持ったフレームワークを使う必要もない。レスポンスの早さとシンプルさが大事になってくる。
そう考えるとやっぱNode.jsかなぁ。非同期の仕組みはやっぱ同時アクセスが頻繁に起こるAPIでとてもいい機能だし。ということでこれも学んでいきたい。
だが今回はクライアント側に目を向けてみる。AndroidはJava, iPhoneはObjective-C, ではPC・スマホのHTMLは?
ここで必要になってくるのは、ご存じJavaScript。こいつがJavaやObjective-Cに替わるような存在にならないといけない。APIと密に連携したJavaScriptフレームワークが望まれる。
「ローカルストレージ」とかHTML5で出てきたけど、これもそういう流れにしていこうと思っているからなのかなぁと思ったら、色々納得ができた。
そんでもって調べてみたら、色々あるんだわこれが。。。
まず思いつくのはbackbone.js。
JavaScriptMVCだ。ヒストリーの管理とかAPI連携の部分が標準で備わっているのがとても魅力に見える。これはGMailのような大規模JSの場合はBackbone.jsでいいと思うけど、個人であそこまで大作を作ることもないだろうし、小規模でも結構色々Backboneだと書かないといけない感じがして、どうかなぁと思った。
そして「JSフレームワークはMVでいい。Cはいらない」ととある方が言ってたのを思い出した。
というわけでBackbone.jsを保留にして他のを調べてみる。
次はKnockout.js。よくBackbone.jsと比較されることが多いみたい。こちらはMVVMというモデルを採用していて、Viewにバインディングのパラメータを書いてそれに基づくコードを書いていくスタイルみたい。
これいいんじゃね？と思ったんだけど、ヒストリー機能やAPI連携部分はフレームワーク内に提供されていないみたいで、ゴリゴリ書いていかないといけない模様。
今回のメインテーマはAPIと連携したJavaScriptだからそれもなぁ、、と思って保留。
次に見つけたのがSpine.js。CoffeeScriptベースでBackbone.jsに影響されたフレームワークらしい。個人的にはRailsでCoffeeScriptかじっていたので、それでもいいなと思っていた。けどこれも結局はBackbone.jsと同じでMVCモデルだ。うーむ・・
これ見ると他にも今はJavaScriptフレームワークが乱立状態で、もう何が何だか。。
JavaScriptフレームワークに関してはもうちょい落ち着いてきたらにしようと決めました。
先にAPIサーバのことを考えてサーバサイドの勉強をしていくか〜
待ってろよ、Node.js ^^
