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.

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.

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.

GraphQL is not terribly bad to interact with. The schema system and field selection is really powerful that you can pick partial results, and that you can use an object oriented way to represent your domain models. It is pretty neat for cross-team collaboration.

Replacing GraphQL and REST + OpenAPI OTOH I think is much more terrible. You have two API description language (one on the URL path, maybe the Zod schema, another one on the OpenAPI schema). Things like tRPC or magic functions are just using Typescript type system and comment to replace the schema that GraphQL already has.

The only thing I would bitch about GraphQL is it is quite hard to build an ad-hoc GraphQL server from the first principle, while REST is really KISS till the end. And GraphQL typically needs a lot more attention to N+1 problem.

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.

mine just is the gh cli. is the advantage of graphql that they can compose a query that would take multiple cli invocations?

All practical GraphQL interfaces constrain you to precisely the query formats that are used by the front end, to avoid queries accidentally reading private data or blowing up computation time.

Having worked on the gh gql api, I wish you luck with timeouts haha

Which is fine, and how these businesses should've been run from the start. Require auth, use the sign-in to increase conversion, that increases revenue, that revenue's used to increase capacity. When free plans become a drain on paid users' experience you're shooting yourself in the foot. If you want to support increasing free use you need to increase paid use. Do that later and the users revolt; do it early and it's normal.

blog post should've been titled, have your agents sign in

My first reaction was that I really like this idea.

If we had a system where people who access projects pay and popular FOSS developers get paid for it we'd have much better alignment.

My second thought was that bots would immediately try to circumvent such a plan. They'd probably spam Gitlab with fake repos to try to harvest those payouts.

I like the idea, but that wasn’t my read.

The guidance given seems to hurt open source projects, not help.

> Make the project private if the traffic is not coming from the audience you built it for, which stops anonymous callers reaching it at all. Or upgrade to Premium or Ultimate for much higher limits.

Three minutes after kickbacks were announced there would be a flurry of new repos being created with bots repeatedly scraping them just to get those kickbacks.

My FF being in French, I was automatically served a French version and I just couldn't understand what I was reading. Each sentence unclear, no link between sentences...

I put the text in to gptzero's AI checker and it came back with being Highly Confident it was 100% AI written. I don't think I've ever seen it that confident that the entire thing was AI before.

Dunno, for folks around here, Claude is important, Gitlab is important and banal press release is important. So all of them together makes it obviously important.

Hmm I don't know if they've updated it, but I'm not smelling any of the Claudisms I know so well. No convoluted sentences, metaphors, therapy-speak, 'it's not' constructions, "load bearing" etc etc.

I've mentioned in other threads, but we have execs at my work sending out emails using Claude. It's hilarious, but not unexpected.

"Write a post about decreasing limits so that this information is as obfuscated as possible."

it's painful to read.

sad days

[dead]

Average, yes, but the way they phrase it, it could be a token bucket or similar, where you can do 60 quick requests and then be blocked for a bit while the bucket refills

RIP NAT

https://gitlab.com/gitlab-org/gitlab

Makes 12 graphql API calls and 2 /api/v4 calls... So you get like 4 pages per hour unauth?

More like you have 60 requests, you can exhaust them in a single second or spread them differently as per your choice.

Doesn’t help with scrapers though. They use a unique IP for each query.

Or a lot more with IPv6.

Hopefully they bump this up.

Browsing open issues or reviewing a few PRs will easily use more than one request per minute.

The limits are based on the average user but I wonder if the most common interaction is to view a readme and bounce.

I don’t know that putting a paywall up to learn from or even consider contributing to public projects is a good thing.

Presumably but I wish they'd also focus on optimizing code/making pages fully cacheable instead of rate-limits and blocking

We need a new non-commercial version of the internet. Free of bots, free of ads, ... you pay to access social media optimized to be interesting enough to be worth paying instead of addictive enough to keep you scrolling to show you more ads.

It may look impossible right now. But what is impossible for real is to continue as we are. The damage that internet does to society is increasing by the day while its value is reduced (economic value, social value).

GitHub's "paid" rate limits are the same as GitLab's free tier, so no, it doesn't help

Because that would go against MSFT's wishes on pushing LLM driven development if they started acknowledging that these tools are more damaging than helpful.

Doesn't GitHub already have rate limiting especially if you are not logged in?

The post is about gitlab but on the subject of GitHub, the rate limit I seem to have for viewing commit history seems to be 0 for logged out users and viewing source files seems to be about 5/hour.

Making the privileged money and giving them the power to manipulate the mass is progress to some.

No progress?!

what are you talking about? it's progressing a lot of money into specific people's pockets