この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
丹内です。
掲題の通り、Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワークに参加してきたので、レポートします。
会場に行くまで
会場の株式会社みんなのウェディングさんは築地駅の近くにあり、アクセスが良かったです。
また、オフィスもとても綺麗でした。
Ginza.rbでは参加前の自己紹介Pull Requestを出す文化なのですが、これを忘れていて、直前の駆け込みPRになってしまいました・・・
自己紹介
最初に自己紹介タイムです。
Pull Requestした自己紹介Markdownを映しながら、簡単に自己紹介をしていきました。
この自己紹介だけでも、最近の流行りや苦労している点が聞けて、非常に興味深いと思いました。
自己紹介を聞いている限り、「実際に触っている人が多いのはvue.js、調べている人が多いのはReact.JS」という印象です。
キーノート:Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷
@kyannyさんのトークです。
詳細は見出しリンク先のスライドをごらんください。
以下は私の印象に残った部分のレポートになります。
おさらい：なぜSPAなのか
webアプリをSPA化する動機についてのおさらいからスタートです。
レスポンスが遅くなるとユーザ体験に悪影響が出ます。スマフォのブラウザではより顕著です。
「このままだと遅くてどうしようもない」という段階になるとユーザ体験の向上を目的としたパフォーマンス対策をするわけですが、
- ネイティブアプリを書ける人を雇って作る
- Webアプリを書くエンジニアがネイティブアプリを書けるようになる
といった方針は、Webエンジニアが多いQuipperではコストが高いという判断が下ったそうで、対策としてwebアプリのSPA化に踏み切った経緯があったそうです。
つまり、「ネイティブアプリには及ばないが、このノロさなら我慢できる」「一番低コストで作れる・維持できる」という妥協案としてのSPA導入でした。
JSフレームワークの紹介
Backbone
最初に採用されたフレームワークです。
期待した通りのUIが作れましたが、コードベースは複雑になってしまったそうです。
曰く、「背骨ではなく、バラバラの骨。そのつなぎ方が分からないと歪になるのでは」とのことでした。
Chaplin
Backboneベースで、より制約が強いフレームワークです。Backboneの次に採用されました。
QuipperにJoinsいたBackbone経験者の方が「Backboneの弊害を解決するため、別のFWが必要」ということで導入が決定したそうです。
採用してみて分かった欠点は、Chaplinは「Chaplin開発者の独自エコシステムの1つ」なので、ユーザによるカスタマイズが難しい部分ということだったようです。
また、幾つか便利な機能があるのですが、それがアプリの性質と合致していないのも、イマイチの点だったようでした。
曰く、「便利な機能は、それが想定している先に到達すると足を引っ張る」とのことでした。
Marionette
Chaplinの次に導入されたフレームワークです。
クライアント環境の回線が遅いこともあって、Quipperアプリが動いていたHerokuの30秒制限に引っかかってしまい、改善を余儀なくされたところで、
- Chaplin開発者がたくさんのOSSを書いていたりして、メンテに不安な点があった
- ドキュメントが不足していたり、あまり良い話を聞かない
- 実際のところ、Chaplinに飽きていた
という点から、これらを解消すべく導入したのがMarionetteだったそうです。
導入してみて下記の利点があり、現在もMaripnetteが使われているそうです。
- DOMとregionが対応している機構が、SPAの作りやすさを実現している
- フロントエンドMVCのファイルをmodule単位でまとめられるディレクトリ構成をとれる
話を聞いてみると、確かにshow()をベースにした作り方は、イメージしやすかったです。
曰く、「フロントエンドやっているとリスク承知でレールを外れなければならない時があるが、そこでフレームワークの縛りが緩いと楽」とのことでした。
React
新機能実装の際、拡張ではなく新規に作って統合という判断が下され、一部で使われているそうです。
RailsとSPAの共存
RailsはAPIとして振る舞うようにするのが良いそうです。app/controllers以下はほぼJSON APIで、リソースは全部JSONで返します。
この場合CROSなどをしなくて良いのですが、最新のフロントエンド環境を利用できないデメリットがあります。
結論として、minifyやpackなど足回りを、Nodeではなくassetspipelineに任せるのが楽ということでした。
SPA向きのAPI設計と実装
Railsアプリ本来のscaffold的なRESTful APIは、SPAのバックエンドとしては向いていないとのことでした。いわゆる「1 Screen, 1 API Call」ではないので、画面表示までに複数のAPIへリクエストを出さなければならないのが、SPAには不向きです。
なので、SPA専用のAPIを1つ用意するのが良いのではないか、とのことでした。
この構成はNetflixが参考になるそうです。Netflixは特殊なクライアント(例えばPS3)専用のAPIがあり、その後ろに堅いRESTfulがあるそうです。
質疑応答
JS環境のテストツールやテスタビリティについて
以下のようなツールを利用しているそうです。
Mocha以外は、私は始めて聞いたツールでした。
テスタビリティについては、Backbone系は「このviewがnewされたらこのイベントハンドラがはられていること」などをテストしやすいそうです。
Quipperではリアルタイム性のためPusherを使っているそうですが、このテストを書くのは難しいということでした。
テストの並列化
フロントエンドのテストはパラレルにしてないそうです。CircleCIではparallelism(課金)によってRSpecの実行を自動で分割してくれるそうですが、フロントエンドのテストは分割されないため、結局は1つのインスタンスでテストするのと同じ時間がかかるそうです。 テストの実行時間は、CIでは10min、ローカルでひと通り流すと20minかかるそうです。
フロントエンド環境で型が必要か
modelではやっぱり型がほしいとのことです。
TSも良いと思う反面、Quipper社内ではそのような動きはあまり無いようでした。
AltJSについて
「Coffeeは補助輪」というのが印象的でした(JSがわからないRailsプログラマがJSを書くときに使う)。
ただ、「Coffeeで大規模になった今、Human ReadableなJSにコンバートするのは難しい」とのことでした。
JSの管理
JSのライブラリ管理は、gemもあり、npmもあり、bowerもありと、カオスになっているようです。
プライベートリポジトリのbootstrapは、git submoduleで管理しているそうです。
フロントのビルド環境は「事故った時に痛い割には、うまく行ってもあまり嬉しくない」ということで後回しになりがちというのが、印象的でした。
振り返り
質疑応答が終わった後、振り返りが行われました。
まず、Ginza.rbへ初参加の人に感想を聞き、次にKPTにより改善アクションを出していました。
その後、次回のお題/日時まで決めきていて、このような工夫が、継続的で良いコミュニティを生むのだと思いました。
まとめ
実際に会場に来てトークを聞くことで、スライドには書いていない「なぜこうしたのか」といった、結論に至る過程を聞くことができ、勉強になりました。
ちょうどReactとRailsを使ったSPAを作りたいと思い手を動かしていたので、個人的には最高なタイミングでした。
次回のお題もWeb APIに関する内容で興味があるので、また参加したいです！
186
