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
フロントエンド メタフレームワーク 選定の際に考えたこと
Search
YuppeEng
November 06, 2024
Technology
0
620
フロントエンド メタフレームワーク 選定の際に考えたこと
11/6(水)【Qiita Bash】推しフロントエンド技術について語ろう!で登壇した内容です。
https://increments.connpass.com/event/328720/
YuppeEng
November 06, 2024
Tweet
Share
More Decks by YuppeEng
See All by YuppeEng
小規模組織において、これから一緒にSREを考える仲間を増やすために実践したこと
yuppeeng
0
520
Other Decks in Technology
See All in Technology
AGIについてChatGPTに聞いてみた
blueb
0
130
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
240
SRE×AIOpsを始めよう!GuardDutyによるお手軽脅威検出
amixedcolor
1
230
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
600
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
7
720
Engineer Career Talk
lycorp_recruit_jp
0
200
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
140
飲食店データの分析事例とそれを支えるデータ基盤
kimujun
0
220
組織成長を加速させるオンボーディングの取り組み
sudoakiy
3
300
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
4
1k
あなたの知らない Function.prototype.toString() の世界
mizdra
PRO
4
1.1k
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Practical Orchestrator
shlominoach
186
10k
RailsConf 2023
tenderlove
29
910
Why Our Code Smells
bkeepers
PRO
334
57k
Docker and Python
trallard
40
3.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Happy Clients
brianwarren
98
6.7k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Transcript
フロントエンド メタフレームワーク 選定の際に考えたこと 2024/11/6 【Qiita Bash】推しフロントエンド技術に ついて語ろう! yuppe(yuppe0328)
自己紹介 中村 友多朗(@yuppe0328) 仕事: アジャイル開発(@KDDIアジャイル開発センター) 趣味: 音楽(ギターなど), アニメ鑑賞, 旅行 興味:
フロントエンドアーキ,コンテナ,ネットワーク, アジャイル開発 Qiita: https://qiita.com/yuppe0328
Q.フロントエンドメタフレームワーク の選定どうしてる? ・フレームワークの人気? ・アプリケーションの要件? ・シンプルに使いたいやつ?
求めていたものは何? ①チームの技術スタック/状況 ・社内小規模プロジェクトのアプリを React使ってSPAで構築した経験あり ・バックエンドFW中心に触ってきた メンバーが多く、いきなりのマインド チェンジは難しい ・各種レンダリングパターンの理解 ・比較的複雑なキャッシュ最適化 ・なるべく複雑性を排除した形で、
UIライブラリにReactを採用 ・クライアントサイドはコンポーネント ベースで開発 ・バックエンドはこれまで通りリクエ ストベースの動的アプリに寄せたい
求めていたものは何? ②アプリケーションの要件 ・業務用アプリケーションではないた め、できるだけ初期リクエスト時のク ライアント側のストレスを減らしたい ・ターゲットの性質上、十分な顧客の端末 スペック/ネットワーク環境が保証できない 可能性がある → レンダリング負荷をできるだけサー
バーサイドに寄せたい ・SPAではなくSSRを利用できる メタフレームワークの採用 ・Next.js? ・Pages Router ・App Router(2023.5〜 stable) →Pages Routerは積極的に 採用しづらい
ぶっちゃけ… App Routerキツそう…? ・まともにSSRするのにuse client境界 を狭めるためのある程度しっかりし たコンポーネント設計が必要 ・外から見てて事前に知ってなきゃ事故る 事象が多いように見える ・キャッシュの仕様
・静的/動的レンダリングを意識しなが らコード書くのも慣れないと大変そう ・爆弾を踏まないに越したことはない (回避すればいいというのはあるが) ・頑張ってキャッチアップした末に得 られるもの(顧客/開発者体験的価値) がそのキャッチアップコストを超える 自信がない ・上手な設計をしなくても/できなくて も同じ価値を実現する方法があるの ならそちらでも良いのでは…
Remixを採用してみました
Remixを採用したわけ ②Next.jsだとまともにSSRするのに use client境界を狭めるための節度 あるコンポーネント設計が必要な気 がした ①バックエンドFW採用時からなるべ く大きなマインドチェンジをせずに使 用できたらいいな ②サーバー/クライアントバンドルを
あまり意識せずともRemix側でよしな にバンドルしてくれ、簡単にSSR可能 ①Remixのシンプルさの所以である フルスタックデータフローがこれまで 自分たちが扱ってきたFWの使い勝 手と非常に近い
①フルスタックデータフローに馴染みやすい
②容易にSSRを実現 build/server ・Remix側でloader/actionとそのimportモ ジュールは自動でサーバーバンドルへ ※./serverフォルダもしくは.server.tsとするこ とで強制も可(clientも同様) build/server & client ・初回リクエスト時はjsx()でHTML化したペー
ジ要素とクライアントサイド依存 (useEffect,State等)のjsファイルおよび manifest(routeごとのassetを記述)ファイルを 返却 ・以降、SPAとして機能
まとめ ①バックエンドFW経験があって、まだReactの世界に慣れきってないメン バーが多い中、要件に照らし合わせて最適だと思う選択肢(Remix)を採用 したら結構上手くいった ②柔軟なキャッシュ戦略を必要とするアプリケーションの作成には Next.jsがマッチするが、そういった要件もなく手軽にSSRを実現したいな ら、Remixを採用すると幸せになれるかも…?