If you are using LLMs to interact with sites like GitLab and GitHub, and you have the option to use a GraphQL API, you should jump on it immediately.
GraphQL is absolutely terrible for human developers to interact with, but it's like Facebook could see into the future back in 2012. I cannot imagine a more perfect API surface for agents. With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out. With GraphQL constraining the results you can easily read hundreds in the same token budget.
Additionally, the # of requests your agents need to make can be reduced in many cases since GraphQL can join across types whereas REST APIs cannot. You essentially get savings in two dimensions here. Quota and raw token volume per logical response.
I work closely with the team responsible for a large, self-hosted GitHub Enterprise instance. This is good advice for clients/consumers of GH data, but it can very easily lead to a lot of strain on the server-side. It’s not obvious what fields that you request are simple reads from tables or actually end up invoking git under the hood.
You could argue the rate limit guards should better reflect that, but that’s just not the reality of the system. Likely speaks to a lot of stability issues GitHub has been facing lately.
Well 1. GitHub is the broken & bad one, and 2. isn't that kind of on them? If they're getting a ton of requests that read data awkwardly, the fix seems like the quintessential data engineering task.
You sound like someone who has not been informed about the problem GitHub is facing. No one else is facing anything close to it, so there is no meaning to "the bad one".
I put my ssh credential behind a tpm and now I notice that every time I switch a chat in ChatGPT it tries to see the current remote status of the branch.
That also doesn’t help with load. So besides what agents are doing themselves the AI companies also have a responsibility of being good citizens.
bob1029 · · focus · HN ↗
GraphQL is absolutely terrible for human developers to interact with, but it's like Facebook could see into the future back in 2012. I cannot imagine a more perfect API surface for agents. With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out. With GraphQL constraining the results you can easily read hundreds in the same token budget.
Additionally, the # of requests your agents need to make can be reduced in many cases since GraphQL can join across types whereas REST APIs cannot. You essentially get savings in two dimensions here. Quota and raw token volume per logical response.
iamEAP · · focus · HN ↗
You could argue the rate limit guards should better reflect that, but that’s just not the reality of the system. Likely speaks to a lot of stability issues GitHub has been facing lately.
bbor · · focus · HN ↗
jeremyjh · · focus · HN ↗
<a href="https://cursor.com/blog/git-at-any-scale" rel="nofollow">https://cursor.com/blog/git-at-any-scale
spockz · · focus · HN ↗
That also doesn’t help with load. So besides what agents are doing themselves the AI companies also have a responsibility of being good citizens.
jeremyjh · · focus · HN ↗