0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

React Server ComponentsとGraphQLの相性について考えてみる

Last updated at Posted at 2024-10-27

最近React Server Componentsの学習を進めていく中で、「GraphQLと組み合わせたらどうなるんだろう?」とふと考えました。どちらもデータの取得を効率化するための仕組みですよね。「重複する部分も多いし、むしろ組み合わせると複雑になっちゃうのでは?」という疑問が湧いてきて、実際に検証してみることにしました。

想定読者

こんな方に読んでいただきたい記事です。

  • React Server Componentsの基礎を押さえている開発者
  • 実務でGraphQLやRESTful APIを使ったことがある方
  • 「次のプロジェクトではRSCを導入したいけど、GraphQLとの兼ね合いってどうなんだろう?」と考えている方
  • Reactアプリのパフォーマンスチューニングに興味がある方

この記事では、実際のプロジェクトでどちらを選ぶべきか、チーム開発の視点も含めて考えてみたいと思います。技術的な比較だけでなく、実装コストやチームの開発効率なども含めて、現場目線で考察してみました。

RSCとGraphQLの相性について考えてみた

最初に思ったのは「RSCとGraphQLって、実は似たようなことをやろうとしてるんじゃない?」ということでした。

たとえば、どちらも以下のような課題を解決しようとしています。

  • 必要なデータだけを取得したい(オーバーフェッチの防止)
  • 複数の依存関係があるデータをスマートに取得したい(ウォーターフォールの解決)

組み合わせる時の「あれ?」ポイント

GraphQLとRSCを組み合わせようとすると、いくつかの「あれ?」というポイントに気づきます:

  1. 実装が複雑になりがち

    • GraphQLのスキーマ定義
    • RSCのデータ取得の最適化
    • 両方の機能を活かすための設計...
  2. ツールやライブラリの制約

    • RSC対応のGraphQLクライアントってまだ少ないですよね
    • 開発ツールも発展途上な感じ

正直、チーム全員がこの2つの技術に詳しくないと、メンテナンスが大変かもしれません。

じゃあRESTful APIならどうか

実は、RSCとRESTful APIの組み合わせってすごくシンプルに書けます。

async function UserDashboard({ userId }: { userId: string }) {
  // シンプルに並列でデータ取得
  const [user, settings] = await Promise.all([
    fetch(`/api/users/${userId}`),
    fetch(`/api/users/${userId}/settings`)
  ]);

  const userData = await user.json();
  const settingsData = await settings.json();

  return (
    <div>
      <UserProfile user={userData} />
      <UserSettings settings={settingsData} />
    </div>
  );
}

App Routerのいいところ

実は、Next.jsのApp Routerには「Request Memoization」という素敵な機能があるんです。これが地味にすごい。

// こんなコードがあったとして
async function getData(id: string) {
  const res = await fetch(`/api/data/${id}`);
  return res.json();
}

// 複数のコンポーネントで同じデータを取得しても
async function ComponentA({ id }: { id: string }) {
  const data = await getData(id);  // 1回目の呼び出し
  return <div>{/* ... */}</div>;
}

async function ComponentB({ id }: { id: string }) {
  const data = await getData(id);  // 実は再フェッチは発生しない!
  return <div>{/* ... */}</div>;
}

同じリクエストは自動でメモ化されるので、パフォーマンスのことをそれほど気にしなくても大丈夫なんです。これ、個人的にすごく好きな機能です。

じゃあ、どっちを選ぶ?

結論から言うと、多くの場合はRSC + RESTful APIの組み合わせをお勧めします。

その理由は:

  1. シンプルに書ける
  2. チームメンバーの学習コストが低い
  3. 既存のツールやノウハウが使える
  4. パフォーマンスも予測しやすい

ただし、以下のような場合はGraphQLも検討する価値があります:

  • すでにGraphQLの基盤がしっかりしている
  • データの要件が本当に複雑
  • クライアント側で柔軟なデータ取得が必須

まとめ

RSCは素晴らしい機能なのですが、必ずしも全ての最新技術と組み合わせる必要はないのかもしれません。時にはシンプルな選択肢の方が、開発効率もパフォーマンスも上がることがありますよね。

特にRSC + RESTful APIの組み合わせは、

  • 書きやすい
  • 分かりやすい
  • メンテナンスしやすい

という、実務で重要な要素が揃っています。

新しいプロジェクトを始める時は、まずはこのシンプルな組み合わせから検討してみてはいかがでしょうか。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?