GitHub API を使ったアプリケーションを作成するときは、API の呼び出し回数制限を意識した設計を行う必要があります。 GitHub API バージョン3 の REST API には、1 時間に 5000 リクエストまでという明確な呼び出し回数制限がありましたが、API バージョン4 の GraphQL API はそのクエリの性質上、ちょっと異なるコスト計算方法が採用されています。
正確な計算方法は上記のサイトに記述されていますが、簡単にいうと、GraphQL クエリの入れ子階層が深くなり、複雑になるほどコストがかかるという計算になっています。
ある GraphQL クエリが実際にどれだけのコストがかかるかは、下記のように rateLimit 情報を取得することで調べることができます。
query {
rateLimit {
limit
cost
remaining
resetAt
}
search(query: "repo:electron/electron is:issue", type: ISSUE, first: 5) {
issueCount
nodes {
... on Issue {
title
labels(first: 10) { nodes { name }}
}
}
}
}上記のクエリを実行すると、次のような感じの JSON レスポンスが返ってきます。
{
"data": {
"rateLimit": {
"limit": 5000,
"cost": 1,
"remaining": 4999,
"resetAt": "2020-08-02T09:15:20Z"
},
"search": {
"issueCount": 13278,
"nodes": [
// ...
]
}
}
}rateLimit の各プロパティの値は次のような意味を持っています。
limit: 5000… 1時間あたりに使用可能なコスト（合計 5000 までのコストの呼び出しが可能ということ）cost: 1… 今回のクエリで消費したコストremaining: 4999… あとどれだけのコストのクエリを実行できるかresetAt: 2020-08-02...… remaining が 5000 にリセットされる時間 (UTC)
つまり、cost プロパティの値ができるだけ小さくなるように GraphQL のクエリを設計するべきだということです。
GraphQL API の呼び出し回数を減らしても、この cost 値が大きいとすぐにリミットに到達してしまいます。