Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
メドピア開発からVueの プログレッシブを俯瞰する
Search
mpg-tomoya-komiyama
June 24, 2021
Technology
2
4.1k
メドピア開発からVueの プログレッシブを俯瞰する
https://techplay.jp/event/780231
2020.6.5のイベントで発表したスライド
mpg-tomoya-komiyama
June 24, 2021
Tweet
Share
Other Decks in Technology
See All in Technology
Googleマップ/Earthが一般化した 地図タイルのイマ
mapconcierge4agu
1
200
トラシューアニマルになろう ~開発者だからこそできる、安定したサービス作りの秘訣~
jacopen
2
1.5k
バックエンドエンジニアのためのフロントエンド入門 #devsumiC
panda_program
16
6.5k
Postmanを使いこなす!2025年ぜひとも押さえておきたいPostmanの10の機能
nagix
2
120
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
190
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
230
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
100
AndroidデバイスにFTPサーバを建立する
e10dokup
0
240
ハッキングの世界に迫る~攻撃者の思考で考えるセキュリティ~
nomizone
12
4.5k
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
550
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
110
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Being A Developer After 40
akosma
89
590k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
It's Worth the Effort
3n
184
28k
The Cult of Friendly URLs
andyhume
78
6.2k
Raft: Consensus for Rubyists
vanstee
137
6.8k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
Code Reviewing Like a Champion
maltzj
521
39k
4 Signs Your Business is Dying
shpigford
182
22k
Transcript
メドピア開発から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