Open3

「Next.jsの考え方」を読む

KeitaUenishiKeitaUenishi

第1部 データフェッチ

データフェッチ on Server Components

データフェッチはClient Componentsではなく、Server Componentsで行うべし。

パフォーマンスと設計のトレードオフ

  • クライアント・サーバー間の通信は、物理的距離や不安定なネットワーク環境によって多くの場合低速になる
    • REST APIにおいて、通信回数を少なくしようとするとGod APIと呼ばれる超デカ責務のAPIになりがち
    • 責務が小さい細粒度なAPIはChatty APIと呼ばれる
      • 通信回数が増えたりデータフェッチのウォーターフォールが発生し、パフォーマンスが劣化しがち

さまざまな実装コスト

  • 多くの場合キャッシュ機能を搭載した3rd partyライブラリを使用するが、その学習コストが高い
  • リクエスト先のAPIは、パブリックなネットワークに公開されるため堅牢なセキュリティが必要

バンドルサイズの増加

  • クライアントサイドでのデータフェッチは、フェッチにまつわる3rd partyなどのいろんなソースがバンドルされてクライアントに送信される
  • つまり、無駄が多くなりがち

サーバーでデータフェッチすることの何がそんなにいいのか

  • サーバー間通信 (Next.jsサーバーとAPIサーバー) は多くの場合高速で、安定しているので、クライアント・サーバー間通信よりも高パフォーマンスになる
  • レンダリングを前提としていないため、3rd partyライブラリを用いず、fetch APIなどのシンプルな実装できる
  • リクエスト先のAPIがパブリックでなくてもよくなるため、セキュリティリスクを軽減できる
  • Server Componentsの実行結果はHTMLやRSC Payloadとしてクライアントに送信されるため、データフェッチライブラリにまつわる実装などは不要になり、バンドルサイズが軽減される

トレードオフ

ユーザー操作とデータフェッチ → 後述

  • GraphQLとの相性が非常に悪い

    • RSCとGraphQLの解決したい問題が被っている (データフェッチ設計のトレードオフ)
    • RSCと連携させるための知見やライブラリが不足しており、実装コストも高くなる

    RSCの最初のRFCは、Relayの初期開発者の1人でGraphQLを通じてReactにおけるデータフェッチのベストプラクティスを追求してきたJoe Savona氏によって提案されました。そのため、RSCはGraphQLの持っているメリットや課題を踏まえて設計されているというGraphQLの精神的後継の側面を持ち合わせていると考えることができます。

なるほど…

KeitaUenishiKeitaUenishi

データフェッチ コロケーション

データフェッチはデータを参照するコンポーネントにコロケーションし、コンポーネントの独立性を高める

コロケーションとは

コードをできるだけ関連性のある場所に配置すること

App RouterではServer Componentsでのデータフェッチが可能なので、できるだけ末端のコンポーネントへデータフェッチをコロケーションすることを推奨している。
同じデータフェッチが何度も実行されてしまうという心配は不要。
App RouterではRequest Memoizationによって、データフェッチがメモ化される。

そのため、Server Componentsでは必要なコンポーネントに対して、必要なデータフェッチ関数を記述する。
( APIリクエストの処理などは別モジュールなどで作成する)