Sometimes it’s necessary to query GitHub for repo information through an API; during a continuous integration (CI) build step for example.
I’ve used GitHub’s REST API before, which is OK but dumps a lot of extra data that can be annoying to parse. Also, sometimes multiple queries are needed to get to the data I actually want.
My recent need to query GitHub looked like a good opportunity to try out the GitHub’s new GraphQL API that will eventually replace the REST API. According to GitHub, GraphQL allows for much more specific and scoped queries.
Following the GitHub Guide, I set up an authentication token and downloaded the GraphiQL app for Mac OS X.
GitHub has a guide for getting started with the GraphQL endpoint, which includes a basic pull requests query example. This could be useful for adding information to build configurations that build and test GitHub pull requests. Based on that guide, I put together a GraphQL query that returns the title and branch that was merged for all merged pull requests in a given repo. I used GraphQL pagination to get the first 10 results and a cursor (endCursor) to page through the rest.
I got the second page of merged pull requests by using the endCursor value as input to the after parameter. Paging should definitely be handled in an application through a properly designed interface, preferably using a GraphQL framework. This is the just the raw view:
I also added a startCursor to test paging backwards:
The GraphQL query returned much less data than the REST API and let me focus on the pull request properties I actually wanted. From now on I’ll be using the GraphQL API instead of REST because the functionality is so much cleaner! GraphQL has a learning curve, but it’s reasonably shallow and worth navigating.