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
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
100
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
1
1.3k
株式会社EventHub・エンジニア採用資料
eventhub
0
4.2k
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
130
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
2
880
Classmethod AI Talks(CATs) #15 司会進行スライド(2025.02.06) / classmethod-ai-talks-aka-cats_moderator-slides_vol15_2025-02-06
shinyaa31
0
170
現場で役立つAPIデザイン
nagix
29
10k
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
15
5.5k
生成AIの利活用を加速させるための取り組み「prAIrie-dog」/ Shibuya_AI_1
visional_engineering_and_design
1
140
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
5.8k
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
240
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
320
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
310
Done Done
chrislema
182
16k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
99
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Facilitating Awesome Meetings
lara
51
6.2k
Six Lessons from altMBA
skipperchong
27
3.6k
For a Future-Friendly Web
brad_frost
176
9.5k
Why Our Code Smells
bkeepers
PRO
335
57k
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