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
120
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
Qiita Bash
mercury_dev0517
2
200
これだけは知っておきたいクラス設計の基礎知識 version 2
masuda220
PRO
24
6.5k
RubyKaigi Dev Meeting 2025
tenderlove
1
170
監視 やばい
syossan27
10
9.4k
AIコーディングワークフローの試行 〜AIエージェント×ワークフローでの自動化を目指して〜
rkaga
3
3.7k
API for docs
soutaro
2
1.3k
Making TCPSocket.new "Happy"!
coe401_
1
1.5k
複雑なフォームの jotai 設計 / Designing jotai(state) for Complex Forms #layerx_frontend
izumin5210
4
1k
AIコーディングの理想と現実
tomohisa
23
31k
Defying Front-End Inertia: Inertia.js on Rails
skryukov
0
490
リアルタイムレイトレーシング + ニューラルレンダリング簡単紹介 / Real-Time Ray Tracing & Neural Rendering: A Quick Introduction (2025)
shocker_0x15
1
310
The Nature of Complexity in John Ousterhout’s Philosophy of Software Design
philipschwarz
PRO
0
110
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
13
1.4k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
660
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Automating Front-end Workflow
addyosmani
1369
200k
Practical Orchestrator
shlominoach
186
11k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.4k
How to Think Like a Performance Engineer
csswizardry
23
1.5k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
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? ◦ ふふ... ままならない、ね • 疎結合な構造を目指しましょう ◦ 他人の書いたコードに依存しない。する場合は、層を一枚挟む ◦ 捨てられるように疎結合にしておく