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
FrontendUp_新規事業で_Remixを採用した理由と対策.pdf
Search
mizuki_r
February 21, 2025
Programming
0
160
FrontendUp_新規事業で_Remixを採用した理由と対策.pdf
Frontend Up! 〜放課後LT大会!(クイズもあるよ!)〜で発表した内容です。
https://dena.connpass.com/event/339749/
mizuki_r
February 21, 2025
Tweet
Share
More Decks by mizuki_r
See All by mizuki_r
税理士ドットコムの 技術的挑戦 #tapioca_lt
rymizuki
0
270
PHPを始めて1年、レガシーシステムにどう向き合っているか #phpstudy
rymizuki
1
690
モダンとレガシー #gotandaem
rymizuki
0
550
Vuexに型を付けるパターンを調べた #gotandajs
rymizuki
0
120
DockerでNodeの開発は厳しいのか? #gotandajs
rymizuki
3
380
マネージャー!きみは何者だ! #gotandaem
rymizuki
0
1.7k
物語を楽しむための物語論
rymizuki
0
510
失敗と向き合う
rymizuki
0
1.4k
社内勉強会と組織の成長を考える
rymizuki
1
2.6k
Other Decks in Programming
See All in Programming
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
200
Benchmark
sysong
0
230
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
170
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
1
360
Webからモバイルへ Vue.js × Capacitor 活用事例
naokihaba
0
740
Spring gRPC で始める gRPC 入門 / Introduction to gRPC with Spring gRPC
mackey0225
2
520
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
970
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
130
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
130
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
0
220
エンジニア向け採用ピッチ資料
inusan
0
140
Claude Codeの使い方
ttnyt8701
1
130
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.7k
We Have a Design System, Now What?
morganepeng
52
7.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Invisible Side of Design
smashingmag
299
51k
Rails Girls Zürich Keynote
gr2m
94
14k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
The Language of Interfaces
destraynor
158
25k
How to Ace a Technical Interview
jacobian
277
23k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
A Tale of Four Properties
chriscoyier
160
23k
Six Lessons from altMBA
skipperchong
28
3.8k
Transcript
新規事業で Remixを採用した 理由と対策 Frontend Up! 〜放課後 LT大会! / Ryo Iinuma
メディカル事業本部 ウェルビーイング事業部 DXソリューション部 ソリューション開発グループ グループリーダー
自己紹介 Ryo Iinuma / @mizuki_r - DeNA from 2022 -
Engineering Manager from 2018 - Web Engineer from 2011 - Perl, PHP, Node, MySQL - Remix, Next, Nuxt(2), AngularJS - DeNA TechCon 2023 Track C
今日話すこと • 新規事業でRemixを採用してみた(3年前〜現在) ◦ 背景 ◦ 決定に至った理由 • 実際に3年使ってみて ◦
良かった点 ◦ 課題になった点 • やってきた工夫・改善 • ライブラリ・フレームワークとの付き合い方 • まとめ
新規事業で Remixを採用してみた
背景:技術選定に至るまで • 当時の私 ◦ PHPer のフルスタック ◦ Nuxt v2でBFFを組んでいた •
当時の事業 ◦ 健診に対する理解を深めたい ◦ 1ヶ月くらいFigma上で議論をしているがなかなか結論がでない ◦ サクッと動くものを作りたい • 当時のチーム ◦ フロントエンド専属は自分のみ ◦ 新卒・インターン、業務委託の参加はあり ◦ React経験者は少なめ
背景:技術選定を始めてから • 当時のフロントエンド情勢 ◦ Nuxt2 → Nuxt3 Beta ▪ 不安定
+ 学び直し でうーん ◦ Next ▪ 戦略・構造の熟考が必要。 MVPで使うには重い ▪ Reactに理解が深いメンバーばかりではない • 求めていたこと ◦ フロントエンド専属人員でなくても書ける ◦ 書き始め→動かす速度までの時間が短い ◦ JSをなるべく書かない
決定に至った理由 • まず公式サイトとチュートリアルを読んだ ◦ 名前はX等で見たことはあるが、当時は言及がかなり少なかった • Loader, Action, Form周りを実装して決意 ◦
説明が理想的すぎて「ほんまか?」とは思った ◦ 疑ったので実際に触り、なんとなく仕組みを理解した ◦ 「これです。これで行きましょう」我、大歓喜 • 特に反論はなかったけど、驚かれた ◦ 当時はほぼ僕一人だったので ... ◦ Ne(u)xtじゃないの? ◦ 「MVPでダメだったら本実装は Nextにしよう」
実際に3年使ってみて
良かった点 : Loader • Loader関数から返したデータを stateとして利用できる • 通信系の処理を実装しなくて済む ので考えることが減る •
state管理不要
良かった点 : Action / Form • Formコンポーネントと組み合わせる とほぼJS不要になる • 返り値はstateなので通信のpromise
が不要
課題になった点 • loader / action 関数に渡されるのが Requestオブジェクト ◦ 様々なパース処理は自前で実装が必要 ◦
肥大化しやすく、処理の見通しが悪化 • Express等のエコシステムの再利用ができない ◦ Remixの前にexpressおけばできた • Formバリデーションは非サポート(良し悪し) ◦ Remix-Validated-Form を使った結果、様々な問題を内包することに • Promiseで通信しないので、直感的ではない ◦ toastとかnotificationみたいな UIの作り方 • Storybookがサポートされてない ◦ context周りの解消が難しかった ◦ 2023-24年くらいにサポートされて助かった
やってきた工夫・改善
expressを前に起き、 AppLoadContextで渡す • HTTP Handler and Adapters を参考に設定すれば expressを前における •
Expressのエコシステムを利用可能 ◦ logger, sessionをAppLoadContext経由でRemixのloader, actionに ◦ passport等も利用可能
Request/Responseを隠蔽するフレームワークの作成 • Requestオブジェクトをパースする層が必要だったのでフレームワーク化した ◦ QueryStringのパース ◦ Bodyのパース ◦ エラーハンドリング ◦
ミドルウェア • 社内で使っているものとは別だが、以下のようなものを作成 ◦ nakadachi ◦ nakadachi-adapter-remix
Inversifyを導入し、 BFFの処理から Remixを切り離した • DIライブラリのInversifyを利用 ◦ FWに依存しない構造を作る ◦ 機能を変更しやすくする ◦
Logger, APIClientなどのカスタ マイズ意図 • Remixを完全に隠蔽 ◦ クラスを実行する関数を、直接 loader, actionに渡す ◦ 最悪Remix捨てても動くように
UI Componentの責務を分離 • pages直下以外でuseLoaderDataなどのRemix固有のhooksを使わないこ とを徹底 ◦ Remixを剥がすかもしれないので ◦ ーーが、 RemixValidatedFormのhookを持っちゃって部分的に破綻
▪ RVFの内部で RemixのContextを参照する ... • Visual, FeatureでComponentを分離してデザイン的関心を分離 ◦ buttonのような link, linkのような buttonをclickableというコンポーネントを用意 することで解消 ◦ ーーが、 CSSプロパティ直接渡せる機能によって部分的に破綻 ▪ 好きに書き換えられちゃうと、 I/Fを用意する意味がなくなる
emotion、突然の死。 1年かけてPandaCSSへ • React Server Componentの台頭 ◦ StyledComponentの思想が廃れ、Zero Runtimeへ ◦
emotionめっちゃええやんって思ってたところへ大打撃 • 若手が勉強会でZeroRuntimeCSS, PandaCSSなどを発表 ◦ MVPから本実装に切り替えるタイミングで「やっちゃう?」 ◦ ほとんどのComponentがそのまま移管されたので、 emotionも残ってし まっていた ◦ が、インターンや新卒たちのお陰で 1年越しにemotionを脱却した
話題は尽きない ... • TurboRepoの運用周り • Formバリデーション周り • Zodの運用周り • PandaCSS周り
• APIClient周り • Logger周り • エラー・例外設計周り • テスト周り • etc… いっぱい話題があるので、 Frontend Up!を追ってくれれば知れるかも!!
まとめ
まとめ • Remix使ってみたけどいい感じだったよ ◦ HTTP通信をクライアントで設計しなくていいのがマジで楽 ◦ 癖の強いところもあるけど、抽象化して隠蔽してなんとかしたよ • このフレームワークから離れるときが来るかも ◦
ーーという考えを持つことは大事だよ ◦ 「突然の死」は、フロントエンド界隈では当たり前に繰り返されてきた • RR?Remix3? ◦ ふふ... ままならない、ね • 疎結合な構造を目指しましょう ◦ 他人の書いたコードに依存しない。する場合は、層を一枚挟む ◦ 捨てられるように疎結合にしておく