勉強の為に引用しました。
http://qiita.com/kaiinui/items/2781219340d427543d08
kaiinui
2014年06月28日に更新
7
ストック
この記事は最終更新日から1年以上が経過しています。
追記
RailsでJS辛い問題に関しての結論：http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5
--
近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。
ViewのJavascriptがRailsから独立している
API層のサポートが微妙
最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。
ViewのJavascriptがRailsから独立している
Railsはとても堅牢。
モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。
必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。
実際、バックエンドはそうそうバグが出ない。
テストも最低限に抑えられていると感じている。
しかし、最近はViewをJavascriptが支配するようになってきた。
JSが無ければViewが適切に動作しないほどに。
ここで残念なことに、Railsは全くJSの世話を見てくれない。
だからか、おおよそ殆どの問題がModel層とJSの不協和で起こる。
計測したことがないから正確には分からないが、少なくとも、Viewが開発/Fixの大部分を占める。
JSがRailsから独立してしまっているからフレームワークの恩恵が受けられず辛い。
モデルを扱うViewModelかControllerに相当するようなコードがViewの中にも入ってしまっていて、DRY/SRP等クソ食らえ状態。
もちろん、テストもしにくい。
Capybaraでpoltergeistなんぞ回してテストしている気分になるのが精一杯だ。
つくづく、Railsは、Railsで閉じていない開発をするのが苦手なのだと感じる。
根本的に、フレームワーク側でViewのJSとModelをグルーしてくれないと、そろそろ辛い。
何が辛いかというと、別にグルーを書くのが辛いのではなく、ちゃんと動いていることを確認するのが辛い。
せっかく結合部分をフレームワークに全任せしているのに、ここだけ原始時代に戻ったかのようだ。
View開発の比重が増してきたから、裏側だけが良い感じに書けても嬉しくなくなってきた。
API層のサポートが微妙
Appにも対応するためAPIを公開したいが、RailsのAPI対応はとても微妙。
Grapeもいいけど微妙。
なんだか、同じことを何度も書かされているような気分になる。
というか、Webを受けるControllerと、APIを受けるController/Grapeを書くのがあからさまに被っている。
確かにちょっと違うことを書いているのだけど、実質は同じ事を書いているはずだ。
まず、ここで同じModelを扱うコードが2つになってしまう。
次に、Railsに限った話ではないけど、サーバもクライアントもAPIを扱うコードを書かなければならない。
クライアント側のAPIを扱うコードというのは、つまりAPIクライアントのことだ。
生URLを毎回叩くなんて正気の沙汰ではないから、ラップするなにかしらが必要で、APIを書く毎に毎回実装する必要がある。
もちろん、扱う言語毎に必要だから、iOSとAndroidをネイティブで書いていれば、APIクライアントは2つになる。
これで、同じModelを扱うコードが4つ。
4つ…DRYとはなんだったのか
（あっ、そういえばJSでも同じようなコードを書いているから、これで5つ！）
どうせRESTかそれに近い形でサーブするのだから、モデルから自動生成とか出来るはずなのだ。
しかし、それだけだと柔軟性がないからか、いまいち辛いし、実用もされてこなかった。
なにかしらAPIを拡張すれば、それだけで破綻してしまいそうになる。
GoogleのProtocol...
