In this article, we will discuss a scenario in which GitHub’s REST API isn’t efficient enough and how GitHub’s GraphQL API helps us in resolving the problems.
We used Octokit’s GitHub REST API Client extensively while working on Git Repository Analyzer project. The use of Node.js asynchronous calls, helped in making simultaneous HTTP calls but there were too many HTTP calls that were made to retrieve the required data. Let’s see how we can overcome the problems by using GitHub’s GraphQL API.
Based on the above requirements, we retrieve the data in the following manner.
Let’s look at the problems faced with the above approach:
Let’s say I want to get the required data from 5 GitHub repositories.
In total we make 306 HTTP calls for getting the Issue and Patch data for 5 repositories based on the search query.
After each HTTP call, only few fields from the response are used for the subsequent calls. Deletion of the unused data from the response becomes necessary so as to reduce the size of the final output.
From graphql.org :
GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
In the above scenario, when we use GitHub’s REST API, we made 306 HTTP calls to retrieve data. All this data can now be received with a very few HTTP calls. We will see the exact count of HTTP calls and the details about the implementation in the next article.
We only receive the data we ask for — nothing more and nothing less. We no longer have the need to delete the unused data.
We no longer need to use different URLs (as in case for REST API calls) for retrieving the data. GraphQL has a single endpoint which is independent of the required data.
Currently, GitHub’s GraphQL API doesn’t support the above use case. A request has been made for the same purpose.
AmrishJhaveri/Git-Repo-Analyzer_Git-Repo-Analyzer - Fetching data from Github using its REST API and than finding patterns in the patches done for…_github.com
Originally published at https://www.linkedin.com on August 18, 2018.