こんにちは！Goodpatchでフロントエンドエンジニアをやってますあおしです。Prottのフロントエンドを担当しています。
先日、JavaScriptでSPA(Single Page Application)の開発を行っている会社で集まり、弊社オフィスにてSPAサービスサミット #1というイベントを開催しました。本日はそのレポートをお届けします！

健康で文化的な最低限度のSPA

img_2808

株式会社ホットスタートアップさんの共同創業者 エンジニアの香月雄介さんの発表です。
ホットスタートアップさんでは「ペライチ」という無料でホームページを制作しているサービスを運営されています。

サービス立ち上げ当初、とにかく早くリリースしたいという一心で選択したjQueryが恐ろしいほどの負債を産んでしまったという話を最初に、どのようにBackbone.jsに移行していったのかというお話をされていました。フッターにあったfooter.jsというjsファイルがいつの間にかサイドバーになっていたという負債っぷりだったみたいです 笑。

まずFrameworkの選定に関して。
BackboneかAngularかで迷ったらしいのですが、以下の観点からBackboneを選択したそうです。

  • カスタマイズ性の高さ
  • 学習コストの低さ

そして移行に伴うリファクタリングは以下のように行ったそうです。

  • 1000行超えているファイルを細かくモジュールに分け、責任範囲を明確に
  • RequireJSにモジュール形式を統ー
  • Backbone/Marionetteを使用

また、移行時にうまくいかなかった例もお話されていて、フロントエンドエンジニアがつくったモジュールをサーバーサイドエンジニアが壊すというのがあったとのこと。
フロントエンドエンジニアがモジュールを作る → サーバーサイドエンジニアが壊す → フロントエンドエンジニアが修正する → サーバサイドエンジニアが…
という負の連鎖が生まれ、なかなか前に進まない状態になったそうです。
この問題を解消するためにフロントエンドの専属チームを作り、フロントを触るときはこのチームのコードレビューを通すという決まりを作ることで解消したそうです。

Prottフロントエンドの今とこれから

img_2812

弊社フロントエンドエンジニアの久保田の発表です。
弊社が運営するプロトタイピングツール「Prott」が抱えている負債とそれに対しての取り組みに関してお話しました。

Prottが抱えている課題として以下の3つがあります。

  • Web標準に沿わないCoffeeScriptで書かれいる
  • 2000行超の神Controllerが存在する
  • ControllerとDirectiveが密結合している

CoffeeScriptの問題に関しては新しい機能をES2015+で開発し、これ以上負債が増えていかないようにしています。
(このProttのCoffeeScriptからES2015+への移行は弊社フロントエンドエンジニアのよしこが過去に登壇したスライドに詳しく書かれているのでご興味あればどうそ御覧ください)

2000行超の神ControllerやController/Directiveの密結合をこれから生まないため今行っていることとして、責務に応じたDirectiveやServiceへの分割を行っています。また、必ずコードレビューを通すことによってより負債のたまりにくいコードになるようにしています。

質問タイムでAngular バージョン2系へアップデートしないのですか？という質問がでました。
これに関しては現在のProttはコンポーネント指向で書かれておらず移行のコストが高いため今のところは考えていません。ただ、今後リニューアルを考えておりその時の選択肢の一つとしてAngular バージョン2系を使うことは検討しています。

また、CoffeeScriptとES2015+の共存でツラいところはないのですか？という質問もありました。
CoffeeScriptはGlobalでやりとりしているものが多く、必要なものをimportで取り入れているES2015+とうまくハマらないところもあったりするのですが、CoffeeScriptから呼びたいES2015+のファイルをAngularのService化するなど少し工夫することでそこまで苦もなく共存させております。

発表スライドはこちら

SPAの論点

img_2821

株式会社ピースオブケイクさんで最高技術責任者である今雄一さんの発表です。
ピースオブケイクさんでは「note」という誰でも気軽に有料コンテンツを投稿できるサービスを運営されています。
今さんの発表では以下3つについてお話されていました。

  • SPAにするべきかどうか
  • Isomorphicにするかどうか
  • フロントエンドのフレームワークをどうするか

SPAにするべきかどうかということに関しては、サービスの内容によって向き不向きがあるとのこと。
サクサクとした動作や複雑な画面構成が求められるツール系、管理画面系のサービスはSPAに向いてるのではないかということでした。また、SPAを作るに上でモダンなJavaScriptに精通したメンバーがいることも必要と話されていました。

次にIsomorphicにするかどうかに関しては以下のようなことを話されていました。
Isomorphicためにフロントサーバーをnode環境にするのですが、サーバーサイドもnodeにしてしまうと、可用性を高めるのが難しいというお話をされていました。具体的にはCPU-boundな処理はnodeのEventloopをつまらせてしまうとのこと。ただし回避策として、画像関連処理や数値計算などをマイクロサービス化して外に出したり、外部のクラウドサービス(Lambdaなど)を検討してもいいのではないかという話をされてました。
そのなかでnoteさんではIsomorphic + SSRをするのなら既存のAPIサーバーはRailsのままにしてSSR用のnodeのフロントサーバーを用意する方法を検討しているが、現実問題そんなに一気に移行できないという悩みも抱えているそうです。

最後にフロントエンドのフレームワークをどうするかという点では、2016年現在はコンポーネント指向が主流になってきたし、SSR前提ならReactが実績豊富で良いとか、でもフレームワークを軽量にしたい場合MithrilやRiotも良いよねなどという話をされてました。
noteさんの場合はAngularを採用されているのですが、AngularはDirty Checkが遅いと画面がもっさりしたりするというデメリットがあるのですが、noteさんの場合はそこまで複雑なDOM構成になっていないので今は困っていないとのこと。Angular バージョン2系にも移行したいという話もされていて、noteさんの場合記事詳細ページが高速に読めることが1番重要なのでこのページがどの程度改善されるかと、移行のコストのトレードオフで判断したいという話をされてました。

発表資料はこちら

パネルトーク

img_2833

株式会社ホットスタートアップ 代表取締役/エンジニア 橋田一秀さんをモデレーターとして迎え、登壇パートで話されてた香月さん、今さんと弊社よりフロントエンドエンジニアのよしこの計4人でSPAについてのパネルトークを行いました。

コードレビューするとき気をつけている点?

Prottでは必ずコードレビューし、レビュー通らないとマージできないようにしています。細かい書き方は好みではなく既存コードとの統一を重視し、細かい書き方に関してはLinterで巻き取れるようにLinterの導入を進めています。また、コードレビューをお願いされたら相手のタスクがとまらないように優先的にやるようにしています。

ペライチさんではレビューをできるかぎり自動化したいと考えていて、そのためにSideCIを導入しているそうです。

改善プロセスは?

ペライチさんでは開発合宿でパフォーマンスを何秒早くできるか？ことをお祭り感覚で行ったり、Mixpanelの数値を毎週のMTGで話し、グロース担当のエンジニアと改善をすすめるということを行っているそうです。

noteさんではJavaScriptのエラーをTrackJSを使って収集したり、パフォーマンスに関してはNewRelicで計測しているそうです。

どのフレームワークを選択したかとその理由

noteではAngularとBackboneで悩んだが、JSに精通した人がいなかったことと、Backboneはコード書く量が多かったこという理由でAngularを選択したそうです。

ペライチさんでもAngularとBackboneで悩んだみたいですが、RequireJSを使ってたのでカスタマイズ性のしやすさからBackboneを選択したそうです。

まとめ

大きめのSPAを数年運用している会社の話をなかなか聞ける機会がないこともあり、貴重なイベントだったと思いました。また、どのサービスもしばらく運用していて同じような悩みを抱えているように感じました。現在抱えている負債や、その負債を返却するために新しい技術にどうスイッチしていくかなどなど。パネルトークの後は懇親会があったのですが、どのテーブルもピザをつまみながら参加者同士で熱くSPAについてお話されていました。

弊社ではがっつりSPAを開発したいフロントエンドエンジニアを募集中です！少しでもご興味ある方はちょっと話聞いてみるか！という軽い気持ちでもかまわないので、ご応募お待ちしています！

Share on

Goodpatch
Goodpatch公式アカウントです。