Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The ''Why'' Behind the GitHub GraphQL API

DZone's Guide to

The ''Why'' Behind the GitHub GraphQL API

Kin Lane is still processing the entire story behind GitHub's decision to go GraphQL.

· Integration Zone ·
Free Resource

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

I wrote a skeptical piece the other day about GraphQL, which I followed up with another post saying I would keep an open mind. I've added GraphQL to my regular monitoring of the space. I don't have its own research area yet, but if the conversation keeps expanding, I will. A recent expansion in the GraphQL conversation for me was Github releasing the GitHub GraphQL API.

In the release blog post, Github provides exactly what I'm looking for in the GraphQL conversation: the reasons why they chose to start supporting GraphQL. In their post, Github describes some of the challenges API consumers were having with the existing API, which led them down the GraphQL path:

  • Sometimes it required two or three separate calls to assemble a complete view of a resource.
  • Responses simultaneously sent too many data and didn’t include data that consumers needed.

They also talk about some of what they wanted to accomplish:

  • Wanted to identify the OAuth scopes required for each endpoint.
  • Wanted to be smarter about how our resources were paginated.
  • Wanted assurances of type-safety for user-supplied parameters.
  • Wanted to generate documentation from our code.
  • Wanted to generate clients.

Github says that they "studied a variety of API specifications built to make some of this easier, but we found that none of the standards totally matched our requirements" and felt that "GraphQL represents a massive leap forward for API development. Type safety, introspection, generated documentation, and predictable responses benefit both the maintainers and consumers of our platform." Some interesting points to consider, as I work to understand the benefits GraphQL brings to the table.

I'm still processing the entire story behind their decision to go GraphQL, and will share any more thoughts in future blog posts. With this major release from Github, I am now keeping an eye out for other providers who are headed in this direction. Hopefully, they will be as transparent about their reasons why as Github has. This kind of storytelling around API design and deployment is important for the rest of the API community to learn from.

Download A Buyer's Guide to Application and Data Integration, your one-stop-shop for research, checklists, and explanations for an application and data integration solution.

Topics:
integration ,github ,api ,graphql

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}