天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

What's "Next" JS Meetupに参加してきた

timeedev.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

What's "Next" JS Meetupは株式会社バベルのうひょさんを基調講演のゲストとしてお迎えして学ぶ、Next.jsをメインとした勉強会です。タイミーからはLTとして2名のフロントエンドエンジニアが実際の開発を通じて得た学びを皆様に共有する予定です。

会の様子

App Router時代のデータ取得アーキテクチャ

基調講演としてうひょさんから、Next.jsのApp Routerに関する話がありました。

データフェッチング

今回の発表では、「アプリケーション外部からデータを取得し、表示に利用すること」をデータフェッチングとして定義するという話がありました。

SSRしない場合は、一般的なクライアントからのfetch以上のことはないのですが、SSRする場合は話がややこしくなるので、フレームワークがサポートする必要があるということです。

React 18前後&RSCリリースの変化

React 18がリリースされる前は、レンダリングの最中にデータフェッチングを行うことは不可能で、Reactアプリケーション外部のAPIを使う必要がある状態だったということでした。

一方で、React 18がリリースされた後は、Suspenseがサポートされるようになったことで、SSR時も非同期的なレンダリングが可能(=Streaming SSR)になり、レンダリングの最中にデータフェッチングが行えるようになったということでした。*1
ただし、Streaming SSRでデータフェッチングを行うと、クライアント/サーバーで同じものをレンダリングすることになったが故に、リクエストの重複排除などを考慮する必要が出てきてしまった点は明確にデメリットとして挙げられるということです。

そこでRSC(React Server Components)の出番になるということで、続いてRSCの説明に入っていきました。
RSC+SSRではクライアント側のレンダリングがサーバーサイドでも行われることになり、サーバー側のコンポーネント内で直接データフェッチングできる点が特長になってくるということです。

App Router時代に目指すべきデータ取得アーキテクチャ

これまでの話を踏まえ、発表の本題として、App Router時代のデータ取得アーキテクチャの話に入ってきました。

App Router時代のデータ取得アーキテクチャでは、サーバー側とクライアント側の連携をRSCに任せ、ユーザーランドで苦労しないようにすることを目指すべきということで、データ取得をサーバー/クライアント2種類に分けて考えるのが重要だということです。

Reactアプリ内でデータ取得を行えるRSCの利点を活かしながらSSR周りの苦労を避けるように、サーバー側で行う必要があるデータ取得をServer Component内で完結させることで、RSCがやってくれる以外でサーバー/クライアントのデータ共有をしないことが重要だという話でした。

Server Component内のデータフェッチング

方針としては、サーバーサイドに関してはFetch on renderでも問題ないと言えるのではないか?という話がありました。

Fetch on renderは一般的に避けられることが多い*2ですが、サーバーサイドではfetchにかかる時間が短いのでパフォーマンスのボトルネックにはならないというのが根拠だそうです。

Server Componentのテスト

Server ComponentのUnit testもクライアントコンポーネントのテストと同じ考え方で問題ないということでした。

具体的には、

という2案が考えられるということです。

クライアント側の状態管理との連携

従来のReatでは、データフェッチングの結果は一種の状態として扱われてきましたが、SCのデータフェッチング結果はクライアントから見れば状態ではなく、一部の状態管理アーキテクチャとの相性が悪い点は難しいというお話が挙げられていました。

【Next.js 13】App Routerへのアップデートに向けて、タイミーのフロントエンド開発で今から取り組んでいること

続いて西浦さんからLTがありました。

App Routerのリプレイスはなかなかしんどく、現在進行系でTimeeさんでも取り組んでいるということで、その際に気をつけていることのLTがありました。

Timeeさんでは、以下の点を気にして移行を進めているということです。

Server Actionsを踏まえたフルスタックTypeScriptの一考察

最後に市岡さんから、LTがありました。

既存のフルスタックTSでは、スキーマを活用して型生成を行うアプローチがあったり、tRPCがあったりしますが、これに対してServer Actionsは良くも悪くも手軽さに大きな差があるということでした。(他にもシリアライズ方式やNext.js特化といった部分も差分はある)

Server Actionsの活用例としては、BFF as Server Actionsなどが挙げられるということで、今後より便利になっていくことが期待されるという話もありました。

会全体を通した感想

久しぶりにがっつり技術的な話が聞ける勉強会に参加することができて楽しかったです。

App Router時代に突入して、今後どうなっていくことが予想されるか?という話が多く聴けたのが個人的には非常に良かったイベントでした。

*1:アーキテクチャ的には、Suspenseの導入によりステートに頼らずにローディング中を表現できるようになった点が特長として挙げられる

*2:fetchの結果レンダリングされたコンポーネントがまたfetchを発火したときに通信が直列化してしまう