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
110
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
260
PHPを始めて1年、レガシーシステムにどう向き合っているか #phpstudy
rymizuki
1
670
モダンとレガシー #gotandaem
rymizuki
0
540
Vuexに型を付けるパターンを調べた #gotandajs
rymizuki
0
120
DockerでNodeの開発は厳しいのか? #gotandajs
rymizuki
3
370
マネージャー!きみは何者だ! #gotandaem
rymizuki
0
1.7k
物語を楽しむための物語論
rymizuki
0
500
失敗と向き合う
rymizuki
0
1.4k
社内勉強会と組織の成長を考える
rymizuki
1
2.6k
Other Decks in Programming
See All in Programming
goにおける コネクションプールの仕組み を軽く掘って見た
aronokuyama
0
120
Kubernetesで実現できるPlatform Engineering の現在地
nwiizo
2
1.7k
AtCoder Heuristic First-step Vol.1 講義スライド
terryu16
2
1k
私の愛したLaravel 〜レールを超えたその先へ〜
kentaroutakeda
12
3.5k
Develop Faster With FrankenPHP
dunglas
2
2.4k
新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学
oguri
7
6.5k
SideKiqでジョブが二重起動した事象を深堀りしました
t_hatachi
0
230
remix + cloudflare workers (DO) docker上でいい感じに開発する
yoshidatomoaki
0
120
Node.js, Deno, Bun 最新動向とその所感について
yosuke_furukawa
PRO
6
3k
php-fpm がリクエスト処理する仕組みを追う / Tracing-How-php-fpm-Handles-Requests
shin1x1
5
820
Windows版PHPのビルド手順とPHP 8.4における変更点
matsuo_atsushi
0
360
リアクティブシステムの変遷から理解するalien-signals / Learning alien-signals from the evolution of reactive systems
yamanoku
2
960
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
25k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
28
1.6k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.7k
Why Our Code Smells
bkeepers
PRO
336
57k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
A Modern Web Designer's Workflow
chriscoyier
693
190k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
118
51k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
177
52k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Testing 201, or: Great Expectations
jmmastey
42
7.4k
Adopting Sorbet at Scale
ufuk
75
9.3k
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? ◦ ふふ... ままならない、ね • 疎結合な構造を目指しましょう ◦ 他人の書いたコードに依存しない。する場合は、層を一枚挟む ◦ 捨てられるように疎結合にしておく