フロントエンドメタフレームワーク選定の際に考えたこと

フロントエンドメタフレームワーク選定の際に考えたこと 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を採用すると幸せになれるかも…?

フロントエンドメタフレームワーク選定の際に考えたこと

フロントエンドメタフレームワーク選定の際に考えたこと

YuppeEng

More Decks by YuppeEng

Other Decks in Technology

Featured

Transcript