Skip to main content

Enterprise Server 3.21 は、現在リリース候補として使用できます。

GraphQL API のレート制限とクエリ制限

GitHubのGraphQL APIは、GitHubのサービスに対する過剰な呼び出し、あるいは悪用の呼び出しに対する保護としてかけられている制限があります。

プライマリ レート制限

GitHub Enterprise Server では、レート制限が既定で無効になっています。 インスタンスのレート制限を確認するには、サイト管理者にお問い合わせください。

サイト管理者の場合は、インスタンスのレート制限を設定できます。 詳しくは、「Configuring rate limits (レート制限を構成する)」をご覧ください。

インスタンスの外部でユーザーまたは組織用のアプリを開発する場合は、標準の GitHub レート制限が適用されます。 詳細については、GitHub Free ドキュメントの「GraphQL API のレート制限とクエリ制限」を参照してください。

ノードの制限

schema 検証に合格するには、すべての GraphQL API calls が次の標準を満たしている必要があります。

  • クライアントは、任意のfirstに対して、last または 引数を指定する必要があります。
  • firstlast の値は 1 から 100 である必要があります。
  • 個々の呼び出しでは、合計 500,000 を超える nodes を要求することはできません。

呼び出し中のノードの計算

以下の2つの例は、呼び出し中の合計ノード数を計算する方法を示しています。

  1. 単純なクエリ:

    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
  1. 複雑なクエリ:

    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: <span class="bluebox">10</span>) {

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

クエリの最適化戦略

  • オブジェクト数を制限する: first または last 引数に小さい値を使い、結果を複数ページに分割します。
  • クエリの深さを減らす: 必要でない場合は、入れ子構造が深いオブジェクトを要求しないようにします。
  • 結果をフィルター処理する: 引数を使ってデータをフィルター処理し、必要なもののみを返します。
  • 大きなクエリを分割する: 複雑なクエリを複数の単純なクエリに分割します。
  • 必須フィールドのみを要求する: 使用できるすべてのフィールドを要求するのではなく、必要なフィールドのみを選びます。

このような戦略に従うことで、リソース制限に達する可能性を減らし、API 要求のパフォーマンスと信頼性を向上させることができます。