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
750
フロントエンド メタフレームワーク 選定の際に考えたこと
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
560
Other Decks in Technology
See All in Technology
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
460
Wantedlyの開発組織における生成AIの浸透プロジェクトについて
kotominaga
2
120
測りにくい成果を測る — BtoB SaaSにおける効果検証への挑戦 / Shirokane Kougyou vol 20
sansan_randd
1
110
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
500
AIエージェント開発用SDKとローカルLLMをLINE Botと組み合わせてみた / LINEを使ったLT大会 #14
you
PRO
0
130
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい勘所を集めてみました! - / How to start Scrum that is not written in the Scrum Guide 2nd
takaking22
2
220
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1.2k
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
230
機械学習を扱うプラットフォーム開発と運用事例
lycorptech_jp
PRO
0
680
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
1
240
S3アクセス制御の設計ポイント
tommy0124
3
210
はじめてのOSS開発からみえたGo言語の強み
shibukazu
4
1k
Featured
See All Featured
Become a Pro
speakerdeck
PRO
29
5.5k
How STYLIGHT went responsive
nonsquared
100
5.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
850
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
820
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Rails Girls Zürich Keynote
gr2m
95
14k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Unsuck your backbone
ammeep
671
58k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
590
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を採用すると幸せになれるかも…?