俺、サービス売って家買うんだ

Swift, Kotlin, Vue.js, 統計, GCP / このペースで作ってればいつか2-3億で売れるのがポっと出来るんじゃなかろうか

SPAサービスサミット #1 に行ってきたよ

イベントレポート JavaScript
f:id:ie-kau:20161025005755j:plain


今日はSPAサービスサミットというSPAでサービスを運営している会社の勉強会に参加してきました。
開発の話とか技術選定の話はよく聞くのですが、すでに数年間運用を続きけているサービスの話を聞くことができとても参考になりました。

参加したイベント
peraichi.connpass.com

参加目的

SPA(Single Page Application)にすると実装が楽しくてモチベーション上がるしブラウザベースでデスクトップアプリにやスマホアプリに近いUIを提供できるので利点は感じつつも、実装コストやFramework依存のリスクは避けられないイメージが有るのでその辺をどう考えているかとか長期にわたる運用をどうしているか主に聞きいてきました。

  • 最近のSPA事情を知りたかった
    • Framework
    • 少しは開発楽になったの？
  • 運用どうよ
    • SPAにしてよかったこと
    • ビルドツール
    • ABテスト
    • デプロイ回数
    • 業種間の連携方法
      • デザイナー - エンジニア
      • バックエンド - フロントエンド

健康で文化的な最低限度のSPA by 香月さん

  • ペライチ
  • 構成
    • Backbone.js
    • CakePHP2
  • 歴史
    • SPAにならざるを得なかった
      • 最初はとりあえずjQuery
        • footer.jsがサイドバーの処理になったり...
    • Backbone.jsかAngularJSでまよった
      • カスタマイズ性
      • 学習コストの低さ
      • なんでもいいから秩序
  • リファクタ計画
    1. 処理を細かくモジュール化
    2. RequireJSのモジュール定義方法に統一
    3. Backbone/Marionetteにしていく
  • 失敗
    • とりあえずデキる人だけで初めた
      • →あまりうまくいかなかったので専門のチームを作った
        • フロントを触るときはレビューを通す

所感

  • Backbone.js現役だな−って思った
    • jQueryで頑張ってるサイトを、ちょくちょく直していって構造を整える分には相性良さそう
  • フロントの専門チームを作ってるのはいいけど人を集めるのが大変そう

Prottフロントエンドの今とこれから by 久保田さん

speakerdeck.com

疑問　

  • AngularJSの使い勝手聞きたい
    • Angularの使い勝手はやっぱりいい
  • Angular2は使わないの？
    • コンポーネント指向になってないのでコストが大きそう

所感

  • CoffeeScriptは役目を終えた

SPAの論点 by 今さん

speakerdeck.com

  • note
  • 論点: SPAにスべきか
    • ツール系 or サービス系?
      • 操作におおじて細かい画面書き換え、機敏な動作、複雑な画面構成が求められるツール系　
    • 開発者軸
    • APIサーバーがすでにある
  • SPAと覚悟
  • Noteの場合
    • 複雑なフォームを作る必要があった
  • 論点: Isomorphicにするのか
    • SSRしないときは、単にAPIサーバーへのproxyとして機能
    • Nodeにする必要あり
      • 並行処理性能は高いが可用性高めるのが難しい
      • CPU-boundな処理はnodeのEventroolpをつまらせる
        • 画像の変換とかはLamdaにながす
      • マルチコアを活かすためにcluster moduleなどで多重化する
    • Front App Server Node - API Railsとか分業させるのが良さそう
  • Noteの場合
    • Angular自体はDirty Checkingが遅いとdisられるがそこまで複雑なDOM構成がないためかそこまでこまってない

所感

  • ブラウザの挙動の再現を強いられるのはマジ
  • Angularで運用しきっている例もでてきてる

パネルトーク

  • 環境
    • Protto
      • Rails
      • mongo
      • MySQL(課金)
    • Note
      • Rails
      • Aurora
      • Redis
    • ペライチ
      • CakePHP
  • SEO
    • GoogleがJSをレンダリングしてくれる
      • してくれなかったよ・・
    • レンダリングた結果をAmazon Auroraにいれてる
  • 技術選定
    • ペライチ
      • カスタマイズのしやすさでバックボーン
  • 改善プロセス
    • ペライチ
      • 開発合宿でペライチのパフォーマンスを何秒早くできるか
      • Mixpanelを入れて毎週MTG、グロスハック担当のエンジニアと改善をすすめる
        • グロスハックの担当のエンジニア!
    • Note
      • JavaScriptのエラーをサーバーに飛ばしてみている
      • パフォーマンスはNew Relicで計測
  • コードレビュー
  • セキュリティ
    • csrfの対策をフレームワークが持っていない限りは気をつけないとまずそう

その他 懇親会で聞いた話等

まとめ

  • 将来的な運用を加味するとSPAでUIの動作テストは必須そう
    • UIの改修頻度は高く、デプロイ回数が多い
    • FWの流行り廃れが速いので下記理由も含めFWの載せ替え可能性が相当高い
      • 採用
      • 処理性能
      • セキュリティ

登壇者の方、運営の方、ありがとうございました〜！