alt Hacker NewsIf 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.
Replies
Although that may be true, the quota at least on GitHub depends on what you're quering. We worked directly with GitHub and a complex enough organisation hit with a GraphQL query can actually hit your hourly app limit before you even get a response.
As for GitLab, having hosted it for medium size organisations (~200 devs) and seeing how monorepo's work (they don't, we had GitLab's team show us that one page view made 50K db queries on our setup), please consult with your local admin team before firing GraphQL at it.
> With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out.
This is a solved problem. They just dump it into a file and `jq` or `rg` to find the stuff they need.
Agents are smarter than you think. They've been hill-climbing for generations in their RL environments.
The ones that get their context window blown out don't survive to launch
I digress, but GitHub's GraphQL API has been neglected for years. Or at the minimum, they have not maintained feature parity with their REST API, so there are a good number of cases where you simply cannot do what you need to do without using their REST API.
Now imagine an API that turns every prompt into a validated query within seconds, no prior schema knowledge required because we're building an index, so the model is not wasting tokens on that task even with multiple megabytes of SDL.
We're building such an API for some of the biggest enterprises in the world. Many of them have very large (federated) GraphQL APIs across tens and hundreds of teams. From an agent perspective it's a lot easier to consume a single unified graph where a single query can span 5 relationships vs making hundreds of N+1 rest API calls across many heterogenous APIs from different teams that all look slightly different.
It depends. There are hidden limits in GitHub’s gql. Some will time out above certain quantities and it’s not documented, which probably means it’s a significant server strain to serve the successful responses. I find I have to maintain a test suite to probe those limits. All this makes REST continue to be appealing if testing the gql load for a service hints at any uncertain limits/instability.
mine just is the gh cli. is the advantage of graphql that they can compose a query that would take multiple cli invocations?
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.