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

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

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.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:
integration ,github ,api ,graphql

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}