GraphQLサーバー

GraphQLは、クライアント側のメリットで知られています。GraphQLサーバーは、最小限のデータベース検索とAPI呼び出し回数で、適切なデータ量を取得するという重要な仕事を担っています。

GraphQL要求は、selection setやfieldなどの操作定義を含むGraphQLサービスのスキーマや、GraphQLドキュメントを使って、サーバーで executed します。

サーバーは以下の手順を実行します。

ドキュメントのパース
操作が複数ある場合は、実行する操作を指定
要求を検証し、失敗した場合はエラーを返す
操作（query / mutation / subscription）の実行

GraphQLサーバーの記述方法には様々なアプローチがあります。GraphQLコミュニティで最も一般的に使われているアプローチを紹介します。

Resolverアプローチ

GraphQLサーバーのコードを記述する上で最も一般的なのアプローチは、スキーマを定義して、resolversで様々な操作やfieldを記述する方法です。

コンテキストベースの特定fieldの処理手順を指示する機能をresolversが担っていると考えてください。

resolverにおける基本的なsignatureを以下に示します。

resolverFunc(data, args, context, info)

data - 親から予め取得していたデータ。
args - 引数のkey-valueのペア、オプション。
context - 要求ごとのステート情報、通常は認証ロジックに使用
info - トラバーサルに使うcontextを選択するためのメタデータ

今では、このresolver関数はGraphQL queryのあらゆるフィールドにおいて実行されるようになりました。

N+1によるパフォーマンスへの影響

例えば、articlesとauthorのリストを取得する必要があるとします。シンプルなREST APIをナイーブなコードで作成すると次のようになります。

fetchData: async () => ORM.getAuthors().getArticles();

ここではデータベースに対してquery（SQL）が2件あります。一つはauthorのリストを取得し、もう一つはauthorごとのarticlesのリストを取得します。

このコードにGraphQLを使ってみましょう。

GraphQL queryを使うと次のようになります。

query {
  author {
    id
    name
    articles {
      id
      title
      content
    }
  }
}

resolverを使うと次のようになります。

resolvers = {
  Query: {
    author: async () => {
      return ORM.getAllAuthors()
    }
  },
  Author: {
    articles:  async (authorObj, args) => {
      return ORM.getArticlesBy(authorObj.id)
    }
  },
}

このコードが実際どのように動作するか考えてみましょう。3件それぞれのauthorに2件のarticlesがリンクされているとします。

最初のresolverによって author が呼び出され、すべてのauthor（この場合3件）が返ります。リレーショナルクエリの articles では、resolverの articles がauthorごとに一回ずつ呼び出されます。このナイーブなアプローチの場合、データベースへのヒットは計4件（authorで1件、articlesで3件）となります。

このアプローチだと、パフォーマンスに明らかな影響を及ぼすことが分かります。