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.
> It’s not obvious what fields that you request are simple reads from tables or actually end up invoking git under the hood.
I'm not familiar with graphql but what would make something "invoke git", is it a technical thing or hyperbole?
All of the queries my agents use select fields like issue title, body, labels, createdAt, updatedAt, etc. That's about it. I would hope that stuff is cached and efficient to read. I do not think GraphQL is a good way to interact with git. Running git on the CLI is the best way to interact with git.
That is true for almost any GraphQL backend not just GHE.
Isn't it kind of part and parcel of any GraphQL deployment to update it efficiently?