Welcome to Miminiverse!

It was a Tuesday night, after launching our pilot to the first cohorts early this year, a surprise that my team member called “The red screen of death”, took a lot of students hostage. We were using REST to retrieve students’ PR content for homework review when suddenly we all experienced the constant “quota exceeded” error. REST works like a person manually clicking through each folder to read all the files. It only returns one blob per request, and a submission costs 1 tree call + 1 call per file. One submission has an average of about 100 files, which means 100 file requests. All submissions share a single server token with a limit of 5,000 REST requests/hour, which caps us at ~50 submissions/hour. With many students submitting on the due date, our system suffered from N+1 problems. It was a real challenge because homework review was the core feature of our application. We were predicting that the AI model could potentially be the first bottleneck to fail when the application is in production with real-time users. No one thought GitHub file fetching would be our biggest issue.

We then implemented smart file filtering using Git Trees API to early detect and exclude irrelevant folders and files to reduce the number of REST trips. But it wasn’t sufficient because keeping REST would still mean N blob requests. Our old approach also required several requests to get merged status, headRefName, and exact commit ID (SHA) for each PR. GraphQL was the one tool we needed to retrieve the remaining file contents and combine all the metadata lookups. Instead of clicking through each folder to read the files like REST, we can click once and receive exactly all the files we need.
Running interleaved A/B benchmark testing shows some significant improvements:

GraphQL rate limit at 5000 points/hr was also tested to ensure we stay under the limit of consumed points. Each batch was capped at 50 files, meanwhile GraphQL cost is 1 point per query. If we have 100 files as example above, it will cost 2 points for each submission. So for 50 submissions/hr, we will need ~100 GraphQL points/hour. That is significantly below the limit.

More importantly, the improvement factor scales with repo size. Ranging from early-course homework to big end-of-course repos, GraphQL allows us to scale the project by reducing the resources needed while increasing performance.

If you are using REST and hitting N+1 API calls, it is worth considering migrating to GraphQL. Some links below to understand more about the differences between these two and migration.

https://docs.github.com/en/rest/about-the-rest-api/comparing-githubs-rest-api-and-graphql-api?apiVersion=2026-03-10&source=—–a075ebd44ce7—————————————

https://docs.github.com/en/graphql/guides/migrating-from-rest-to-graphql