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
170
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
「App Intent」よくわからんけどすごい!
rinngo0302
1
110
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
15
5.6k
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
870
ニーリーにおけるプロダクトエンジニア
nealle
0
950
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
230
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
300
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
180
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
180
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
99
37k
型で語るカタ
irof
0
700
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
620
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
0
360
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Automating Front-end Workflow
addyosmani
1370
200k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
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? ◦ ふふ... ままならない、ね • 疎結合な構造を目指しましょう ◦ 他人の書いたコードに依存しない。する場合は、層を一枚挟む ◦ 捨てられるように疎結合にしておく