ノードの制限
スキーマ検証に合� �するには、すべての GraphQL API 呼び出しが次の標準を満たしている必要があります。
- クライアントでは、すべての接続で
first
またはlast
引数を指定する必要があります。 first
とlast
の値は 1 から 100 である必要があります。- 個々の呼び出しでは、合計 500,000 個を超えるノードを要求することはできません。
呼び出し中のノードの計算
以下の2つの例は、呼び出し中の合計ノード数を計算する方法を示しています。
-
単純なクエリ:
query { viewer { repositories(first: 50) { edges { repository:node { name issues(first: 10) { totalCount edges { node { title bodyHTML } } } } } } } }
計算:
50 = 50 repositories + 50 x 10 = 500 repository issues = 550 total nodes
-
複雑なクエリ:
query { viewer { repositories(first: 50) { edges { repository:node { name pullRequests(first: 20) { edges { pullRequest:node { title comments(first: 10) { edges { comment:node { bodyHTML } } } } } } issues(first: 20) { totalCount edges { issue:node { title bodyHTML comments(first: 10) { edges { comment:node { bodyHTML } } } } } } } } } followers(first: 10) { edges { follower:node { login } } } } }
計算:
50 = 50 repositories + 50 x 20 = 1,000 pullRequests + 50 x 20 x 10 = 10,000 pullRequest comments + 50 x 20 = 1,000 issues + 50 x 20 x 10 = 10,000 issue comments + 10 = 10 followers = 22,060 total nodes
レート制限
GraphQL API の制限は、REST API のレート制限とは異なります。
APIのレート制限が異なっているのはなぜでしょうか? GraphQL では、1 つの GraphQL 呼び出しで複数の REST 呼び出しを置き換えることができます。 単一の複雑なGraphQLの呼び出しが、数千のRESTリクエストと等価なこともあります。 単一の GraphQL 呼び出しは REST API レート制限を大幅に下回りますが、クエリはGitHub のサーバーが演算するのと同等の� 荷になる可能性があります。
サーバーでのクエリのコストを正確に表すために、GraphQL API では呼び出しの レート制限スコア を正規化されたポイントのスケールに基づいて計算します。 クエリのスコアは、親のコネクションやその子のfirst及びlast引数を計算に入れます。
- この式では、MySQL、ElasticSearch、Git などの GitHub のシステ� の潜在的な� 荷を事前計算するために、親のコネクションとその子の
first
およびlast
引数が使用されます。 - 新しいコネクションはそれぞれ独自のポイント値を持ちます。 ポイントは呼び出しからの他のポイントと組み合わされて、全体としてのレート制限スコアになります。
GraphQL API のレート制限は、1 時間あたり 5,000 ポイント です。
1 時間あたり 5,000 ポイントは、1 時間あたり 5,000 回の呼び出しと同じではないことに注意してく� さい。GraphQL API と REST API では異なるレート制限が使用されます。
注: 現在の式とレート制限は、開発者による GraphQL API の使用状況に鑑みて、変更される可能性があります。
呼び出しのレート制限のステータスを返す
REST API では、返された HTTP ヘッダーを検査することで、レート制限の状態を確認できます。
GraphQL API では、rateLimit
オブジェクトのフィールドに対して問い合せることで、レート制限の状態を確認できます。
query {
viewer {
login
}
rateLimit {
limit
cost
remaining
resetAt
}
}
-
limit
フィールドには、60 分のウィンドウ内でクライアントで消費できる最大のポイント数が返されます。 -
cost
フィールドには、レート制限に対してカウントされる、現在の呼び出しのポイント コストが返されます。 -
remaining
フィールドには、現在のレート制限ウィンドウ内に残っているポイント数が返されます。 -
resetAt
フィールドには、現在のレート制限ウィンドウが UTC エポック秒単位でリセットされる時刻が返されます。
呼び出しの実行前にレート制限スコアを計算する
rateLimit
オブジェクトに対して問い合せると呼び出しのスコアが返されますが、その呼び出しを実行すると制限に対してカウントされます。 このジレンマを避けるために、呼び出しのスコアを実行前に計算することができます。 次の計算では、rateLimit { cost }
で返されるのとほぼ同じコストが計算されます。
- 呼び出し中のそれぞれのユニークなコネクションを満たすために必要なリクエスト数を� 算していきます。 すべての要求が
first
またはlast
引数の制限に達するとします。 - その数字を 100 で除算し、結果を丸めて最終的な集計コストを取得します。 このステップは、大きな数値を正規化します。
注: GraphQL API に対する呼び出しの最小コストは 1 であり、これは 1 つの要求を表します。
以下は、クエリとスコアの計算の例です。
query {
viewer {
login
repositories(first: 100) {
edges {
node {
id
issues(first: 50) {
edges {
node {
id
labels(first: 60) {
edges {
node {
id
name
}
}
}
}
}
}
}
}
}
}
}
このクエリを完了するには、5,101リクエストが必要です。
- 100 個のリポジトリが返されますが、API でリポジトリのリストを取得するために表示者のアカウントに接続する必要があるのは 一度 � けです。 したがって、リポジトリの要求 = 1 です
- 50 個の Issue が返されますが、API では Issue のリストを取得するために 100 個のリポジトリそれぞれに接続する必要があります。 したがって、Issue の要求 = 100 です
- 60 個のラベルが返されますが、API ではラベルのリストを取得するために潜在的に合計 5,000 個の Issue のそれぞれに接続する必要があります。 したがって、ラベルの要求 = 5,000 です
- 合計 = 5,101 です
100 で除算して丸めると、最終的なクエリのスコアは 51 になります。