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
700
モダンとレガシー #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
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
480
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
260
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.3k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
5.6k
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
550
チームのテスト力を総合的に鍛えて品質、スピード、レジリエンスを共立させる/Testing approach that improves quality, speed, and resilience
goyoki
5
870
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
220
効率的な開発手段として VRTを活用する
ishkawa
0
140
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Raft: Consensus for Rubyists
vanstee
140
7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
The Invisible Side of Design
smashingmag
301
51k
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? ◦ ふふ... ままならない、ね • 疎結合な構造を目指しましょう ◦ 他人の書いたコードに依存しない。する場合は、層を一枚挟む ◦ 捨てられるように疎結合にしておく