メドピア開発からVueの プログレッシブを俯瞰する メドピア株式会社 小宮山智也 https://techplay.jp/event/780231

自己紹介 - 所属: メドピア株式会社 CTO室 - 平成元年生まれ、令和元年メドピア入社 - CTO「フロントエンドテックリードとか言っちゃいましょう！」 - ご趣味は - ランニング（大会絶滅） - 水泳（プール閉鎖） - ボルダリング（肩故障してからご無沙汰） - スキルセット - Vue >> React >>> Angular - フロント >> バック

前知識: CTO室？ - 1 - CTO室所属のフロントエンドエンジニアという視点 - プロダクト横断で様々な厄介ごと趣のある事案が舞い込んでくる

前知識: CTO室？ - 2 - 多様なプロダクト開発環境に関わる機会がある - 歴史ある巨大なRailsプロダクト - Nuxt利用の新規プロダクト - 多数のプロダクト横断で共通する要素 - 【LT趣旨】そんな視点からVueを俯瞰していく - 定数: Ruby on Rails, Vue.js - 変数: プロダクトのフェーズ , 開発体制など

前知識: メドピア開発陣のスキルマップ - イメージしやすいよう乱暴に読み替え - バックエンド = Rails、フロントエンド = Vue - メドピア開発部のパワーバランスはバックエンド > フロントエンド - 必然的に、バックエンド要員もフロントエンドを触る 特に悪意はないパワーバランスイメージ

RailsとVueの交差点 - いわゆるviewの部分を如何に実装するか？ - helper, erb, template, component, etc... - フロントエンド実装方法の大雑把な分類 - 完全Rails - RailsメインでVueがサブ - RailsはサブでVueがメイン - 完全Vue - [注記] - 登壇者はフロントエンド独立原理主義者なので視点の偏りあり - Rails力は微々たるもの - 時間が蒸発するので CSSの話題には踏み込みません

分類ごとの考察

完全Rails - 神は「Railsあれ」と言われた。するとRailsがあった。 THE END

RailsメインでVueがサブ - 1 - Railsの支配下（erb, hamlなど）でviewが作られる - helperでカバーしきれない動的な処理をVueに任せる - 特徴 - templateはerb側に記述されることが多い - Vueの役割はjQueryの代用と言えなくもない

RailsメインでVueがサブ - 2 - メリット - Vueに任せたい処理がなければ純粋に Rails way - helperを最大限活用可能（form_withなど） - 凝った画面でなければ簡単に作れる（多分） - SSRになる - 辛いところ - 多数の言語が混ざる（ ruby, js, html） - RailsとVue両方の知識が求められる - VueのSFC（.vueファイル）という仕組みが活かしにくい（ lint, unit testなど） - viewのテストはE2E頼み - Vue以外の第三者がDOMを触れてしまう - jQuery「お待たせ！」 - コンポーネントの境界が薄い（ v-slotという強力な武器が諸刃の剣に化ける）

RailsはサブでVueがメイン - 1 - Railsは最低限のviewを作るだけ - rootコンポーネントのmountポイント、コンポーネント渡す propsの値など - viewの具体的な実装はVue側で行う - 特徴 - erb側の実装がほとんど消え、 Vue側に移される - erbに残るのはテンプレ的な記述と、 propsへの値受け渡しのみ

RailsはサブでVueがメイン - 2 - メリット - RailsとVueのインタフェースが絞られる - propsで受け取り、ajax（submit）で投げる - Vueの世界で画面実装可能 - Railsの知識はほぼ不要 - コンポーネント単位でテスト可能 - 辛いところ - SSRではない - 渡したい値は全てpropsに詰め込む必要がある - 雑にjsonで渡すとセキュリティリスクあり

完全Vue - 神はバックエンドとフロントエンドとを分けられた。 THE END

完全Vue - 1 - RailsとVueのインタフェースはAPIだけになる - RailsはAPIを提供するだけの存在 - erbは理論上消える - バックエンドとフロントエンドが分離される - リポジトリごと分離することも可能

完全Vue - 2 - メリット - RailsとVueが混ざらない - API実装と画面実装で必要なスキルが分離される - APIというインタフェースが強調される - Open APIなど強力なツールがある - Railsなしで画面実装が可能 - APIをモックするだけ - 辛いところ - 当然ながらRails wayではなくなる - Vue力が求められる - Rails力でカバーが効かない - E2Eが難しい

我々はどれを選ぶべきなのか？ - どの方針もそれぞれメリットと辛さがある - ◯◯「レールに乗ってしまうのがソリューション」 - ◯◯「時代の流れはマイクロサービス」 - ◯◯「Elmを使う」 スキルセット Rails Vue 完全Rails 完全Vue

せっかくなのでアンケート - 現在関わっている開発に最も近いのは 1 ~ 4 の中のどれ？ - 状況が許すなら 1 ~ 4 の中で目指すのはどれ？ - 回答は適当にチャットにでも（例: 1, 4） スキルセット Rails Vue 完全Rails 完全Vue ① ② ③ ④

あるフロントエンドエンジニアの見解 完全Vue一択 それ以外は認めない 開発陣のスキルマッ プ次第だよね

（おもむろにチャットを眺める）

実際メドピアでは 完全Rails 完全Vue - 完全Railsはさすがにもうなさそう => 社内に資料共有したら見つかってしまった - 他は全部ある - 完全Railsから徐々に右へシフトしていくものもある - 新画面での試み、既存画面のリファクタなど - 右端目掛けて一足飛びするものもある - いわゆるリプレイス - 左へのシフトはまだ観測していない

分類のグラデーション - 開発の理想と現実はもちろんあるとして、このようなグラデーションが成立する（諸 説あり）のは実はすごいことなのでは？ - これらの分類はそれぞれ切り離されているわけではなく、徐々に移行していくことも 可能というのは実はすごいことなのでは？ 完全Rails 完全Vue そんなおいしい話が本当にあるんですか？

https://jp.vuejs.org/index.html

プログレッシブなまとめ - 多様なプロダクトを抱えるメドピアでは、Vueのプログレッシブさがいい感じにマッチ している - 良くも悪くもどう使うかは開発者次第 - 実際なんとかなってる（諸説あり）から、どんなプロダクトフェーズで入れてもきっと なんとかなる - まだまだ少数派のフロントエンド勢力拡大のためにメドピアでは積極採用中！！！！ - 俺色に染め上げてやるぜな React勢も歓迎！！！！

ご静聴ありがとうございました 余り時間でQ&A