angular2とRuby on rails

Question

現在、Ruby on rails、javascript、jQueryなどで
既に作成されたwebサービスのフロント側をangular2で書き換えようかと検討
しているのですが、

この書き換えでどのくらいの、どのようなメリットがあるのでしょうか？

既存のアプリケーションには、ユーザー個別の管理画面などがあるので、検討を考えているのですが
学習コスト・導入コストに見合うメリットをどれくらいで得られるか教えて頂きたいです。

Answer 1

Angular2はフレームワークなのでrailsと同じように、そのフレームワークだけでアプリケーションを構成できるように作られています。railsで作ったフォームをAngular2で使い回すといったことは基本的にどちらかの機能を犠牲にすることになります。
現状sprocketsなどとの共存は出来なくなると思います。要はまともに書き換えようとすればアプリケーションをほぼ丸々書き換えるレベルのコストが発生します。特にjqueryで書かれている資産をほとんど捨てることになります。またAngular wayという言葉があるようにAngularは独自の概念を多量に含むので初期の学習コストが非常に高い事で有名で2になってもその点はさほど変わりはありません。またnode.jsを全く触った事なければそちらの学習コストも必要になります。

Angular 2のソースコードは普通のjavascriptのようにsrcで配置すれば読み込めるというようなものではなく，webpackなどでビルドの管理をする必要があり，実際のプロダクトに対して自由自在に設定できるまで学習するのは相当気合がいります。また,公式リリースから日が浅くまだまだ情報が少なくrailsに組み込むことを考え実行している人は,そんなに多くはいないので更に学習コストが高くなるでしょう。

新たにアプリケーションを作成し，それをrailsでルーティングしAngular2のソースコードに変数のみ渡す運用などは出来るかもしれません。しかし,それもそれでAngular 2またはrailsの機能を犠牲にすることになります。

ここまでは,デメリットばかりあげましたが、書き直すということに対してのデメリットであり,新規開発で採用するメリットは沢山あります。jQueryでは,共同作業をしているとUI操作のセレクタに一貫性がないコードが書かれていたり,冗長な記述によってファイルが肥大化したり，毎回無駄なdomの全探索を行うようなコードが散見しやすくなる(最適化していれば速いですが複数人絡むプロジェクトでUIの設計方針を厳密に決めるのはほぼ不可能)のに対して,Angular 2などのVirtual DOM型のviewでは,コンポーネント毎に独立させる書き方によって互いの干渉を最小限に抑え見通しをよく出来ます。
Angular 2のメリットはコンポーネントとモデルの密な結合，コンポーネント同士は疎な結合にすることで，相互作用によってぐちゃぐちゃになりやすいview内のuiを綺麗に切り離せること，他言語のようにモデルのデータ構造をjavascriptに渡さなくても，モデルの構造がjavascriptで定義されているのでサーバ側もクライアント側も同じようにデータの処理が出来ること，クライアント側の中にステイトを持たせられるため，サーバにアクセスしなくてもクライアント内で画面の書き換えが継続出来てサーバー負荷を減らせるSPAを構築しやすいこと。またuiとモデルが相互に値の更新が同期される関係であるためサーバーの変更をクライアントにも反映させるオブザーバブルパターンのアプリケーションが構築しやすいという大きなメリットがあります。更にMVCより大規模開発の際に安全とされているfluxパターンという開発モデルをサポートするライブラリを組み込みやすいように設計されています。

Angular 2は学習コストこそ高いものの素晴らしいフレームワークであることは間違いないです。ただrails(というより他のフレームワーク全般に言える)との相性は恐らくとても悪いと思います。

railsのクライアントサイドのみを整理して速くしたいのであればreactやvueなどを使う方が導入が比較的楽で学習コストもAngular 2ほどでなく今までの資産を大きく損なわなくて済む気がします。

これらの違いは上記二つはライブラリやパッケージで，アプリケーションやフレームワークへの導入の親和性が高くなるように出来ていて,フレームワークと用途が違うからです。

これらが開発の参考になればと思います。

Answer 2

学習コスト・導入コストに見合うメリットをどれくらいで得られるか

一般的に、サービスのスケールが大きいほど、メリットも大きくなります。

そもそも、Googleのスケールが大きいから、
Angularを開発してメリットを得られるわけです。

そこまで極端に大きくなくても、あるていど規模が大きい商業サービスだと、
少ない人数で開発できるとか、サーバのマシンを減らせるとか、
アクセスや売上などが増えるとかで、元が取れる場合があります。

もともとAjaxからして、クライアント側に処理を任せることで、
サーバ側の負荷を軽減する側面があったわけです。その延長線上です。

---

逆に、サービスのスケールが小さいほど、デメリットが大きくなります。

まず、書き直しになりますし、学習コストもあるので、
新しいサービスを一から作るのと同じ労力がかかります。

それで、少人数になるほど分業しにくいです。個人開発なら全部ですし。
フロント専門か、フルスタックでやるかどうかで、学習負荷が全然違います。

だから、理想を追求するなら、常に最新FWを使いたいでしょうが、
現実的には中小規模だと、少々レガシーでも、だましだまし運用します。

また、将来的にフレームワークが廃れてしまうと、
保守の都合で再度の書き直しになることも想定できます。

「これからは、AngularよりReactだ」みたいな、
（一部の）ネットだと、そんな雰囲気がありましたが……。

---

ですから、判断の基準のひとつに、スケールの規模感があります。

Googleのように、組織が大きいと発言力も大きく、大規模FWが注目されますが、
もし小規模なら小規模フレームワークも選択肢です。Vue.jsとかRiot.jsとか。

さて、ここでご質問の話に戻って、Angularのメリットを言えば、
SPAが作りやすいです。ひいては高機能なWebアプリが作りやすいです。

分かりやすいイメージで言うと、もし、GoogleのGmailが少し操作するだけで、
いちいちページ遷移してたら、すっごく使いにくくなってしまいますよね。
そういうアプリを作れる企業にとっては、強烈なメリットになります。

べつにWebアプリじゃなくても、管理画面とかにも向いていますが、
管理画面のためだけに導入して、はたして割が合うかどうか分かりません。

だから、ページ遷移を発生させるかどうかも基準のひとつです。
Webサイト的なベタなページ遷移でいいならjQueryでいいです。

もし、小規模なのにSPAにしてしまうと、SEOで困るケースが出てきます。
大規模は広告で人を集められますが、検索だよりの小規模には死活問題です。

最後にまとめると、大規模なWebアプリならメリットがあります。
小規模なWebサイトなら現状維持でも構わないです。

Answer 3

こちらのトピック、とても興味深く拝見しました。先にコメントされている方のご意見でほぼその通りかと思いますが、Angular1 + Rails（Grape）の組み合わせで仕事をしたときの感想を書いてみます。

わたしはフロントエンドは専門にしていなくて、jQuery（JavaScript）の知識はかじった程度でした。
ですが、過去にフロントがFlex, バックエンドがSOAPといった内容を担当したことがあったので、Angularはその作り方にとても良く似ていて、スッと入れました。

バックエンドは全てGrapeでAPIを作り、jsonでのやりとりでした。ですから、Rails側はcontroller, viewは全く使いませんでした。API担当側は画面を意識しない分、内部の実装に専念できました。
フロント側も、APIが返す想定のjsonのモックを使って画面を実装していったので、時折ハマリがちなRailsの環境構築のストレスも無く、それぞれ独立して作業しやすかったです。

画面系のテストの際は、サーバ側（API）を立てなくとも、モックのjsonとの組み合わせでエラーメッセージやバリデーションといったe2eテストがしやすかったです。

特に、フロントでの入力バリデーションのための仕組みが一通りそろっていたので、入力内容に精度を求められる業務系Webアプリには大変有効だと思います。サーバサイドに送信してから全部やりなおし、といった残念なことを減らせるため、効率を求められる業務システムには向いていると思います。
多言語化対応もしやすかったです。

表（テーブル）やグラフ系のプラグインも豊富ですので、Kibanaとかに見られるようなダッシュボード系にも向いていると感じました。

---

デメリットというか、これはちょっと...というのは、やはりSEOのあたりです。

あとは、完全にAPIとフロントを分離すると、フロント側に動作のロジックを記載する必要も出てきますが、所詮はブラウザで見えないとフロントは動きませんから、JSやCSSの難読化をかけていたとしても、ソースをみればロジックがある程度バレてしまいます。
あまりオープンにすべきでない定数とか接続先なども見えてしまいますので、CtoCで認証もないようなケースでの利用にはちょっと怖い気がしました。

また、APIが出揃ったとして、非同期処理での複数のAPIをうまく期待したとおりの順番で実行して結果を表示するかとか、頭をなやませました。最初は最低限必要なAPIを用意しましたが、それでは粒度が細かすぎてフロントで個別に呼ぶのが厳しすぎるので、複数のAPIをラップするような動きをするAPIが必要になりました。
このあたり、アプリなどでは当然の技術かもしれませんが、それまで意識していなかったので...

結局、基本は簡単でも細かい制御をしたい時にcoffeeとかJSで処理を書かないといけなくて、なかなか情報がないので苦労しました。
その割に、わたしはjQueryをあまり理解してない立場で取り組んだものですから、CoffeeやAngular向きのスクリプトは書けるけれど、jQuery相変わらずわからない...といったいびつな感じになりました。

あとは、CoffeeScriptで記載したり、Angular2のようにTypeScriptが前提になったりすると、それまで必要のなかった（？）ビルド、という作業が必要になってきます。

このへんのnodeのしくみ、ビルドの仕組み、バージョンとの依存関係の仕組みで、思ってた通りにビルドできなかったことがあってハマりました。（プロキシ環境下だと大変です）

---

個人的には、新規で作成する業務系アプリや、機能を非常に限定して画面遷移を少なく、かつサクサク切り替えができるダッシュボード系の画面に向いていると思います。
Rails側ではAPIのみでしたが、それはそれでアプリやほかの仕組みからも呼び出しやすいので、切り分けはよかったとは思います。フロントがまるっと違うフレームワークになったとしても、後ろは使えますから。