{"id":4474,"date":"2017-06-15T18:29:58","date_gmt":"2017-06-15T18:29:58","guid":{"rendered":"https:\/\/redmonk.com\/jgovernor\/?p=4474"},"modified":"2017-06-16T15:19:14","modified_gmt":"2017-06-16T15:19:14","slug":"what-is-graphql-and-why-should-you-care-the-future-of-apis","status":"publish","type":"post","link":"https:\/\/redmonk.com\/jgovernor\/what-is-graphql-and-why-should-you-care-the-future-of-apis\/","title":{"rendered":"What is GraphQL and why should you care? The future of APIs"},"content":{"rendered":"

 <\/p>\n

<\/p>\n

“We’re going GraphQL, we’re replacing everything with GraphQL”<\/p>\n

Sid Sijbrandij, GitLab founder and CEO<\/p>\n<\/blockquote>\n

GraphQL<\/a> is an open source technology created by Facebook that is getting a fair bit of attention of late. It is set to make a major impact on how APIs are designed.<\/p>\n

As is so often the case with these things, it\u2019s not terribly well named. It sounds like a general purpose query language for graph traversal, am I right? Something like Cypher<\/a>.<\/p>\n

It isn\u2019t. The name is a little deceptive. GraphQL is about graphs if you see everything as graphs, but reading the the excellent, crisp docs<\/a> GraphQL is primarily about designing your APIs more effectively, and being more specific about access to your data sources.<\/p>\n

\u201cGraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data.\u201d<\/p>\n

With REST you can only pass a single set of arguments, but with GraphQL you can access a particular field or nested object without making multiple API fetches. You can call many resources in a single request. That in itself is a win. GraphQL has a set of standard types but you can also set custom types. A GraphQL query is a string sent to the runtime that returns JSON to the client.<\/p>\n

Ah\u2026 I remember having a really similar feeling when I first came across jQuery, which is for adding flare to Javascript apps.<\/p>\n

A few weeks back Chris Wanstrath, GitHub\u2019s CEO, said all GitHub APIs would be developed GraphQL-first from here on in. This announcement came during a section labeled The Future of APIs at GitHub\u2019s Satellite conference in London. Wanstrath said GitHub needs to engineer differently because its site gets more API calls than UI visits. Now when we GitHub builds a new feature first it builds a GraphQL API, which it then uses internally before roll out. One suggested graph use case was suggested reviewers for code. GitHub\u2019s project boards are also now backed by GraphQL – and the service is seeing 125m queries per day.<\/p>\n

More and more companies are seeing APIs as their primary access mechanism. Twilio, for example, one of the few successful IPOs in tech of recent times. REST, which has got us through the last few years of Web engineering, is looking a little creaky.<\/p>\n

Github is not alone. The NY Times has just gone through a major back end redesign.<\/p>\n

https:\/\/twitter.com\/wonderboymusic\/status\/875006245190684673<\/p>\n

So what about Facebook? It built GraphQL because it needed something powerful enough to describe Facebook\u2019s API structure, but easy to learn by mobile developers. It is seeing billions of API calls a day now, so we know it scales. As Facebook points out, the shape of the query mirrors the shape of the response, which is cool.<\/p>\n

<\/p>\n

The tree-based shape of the queries is one thing that attracted Neo4J to GraphQL. As a native Graph database it\u2019s interested in the possibilities of extending GraphQL, with Cypher, but not modifying it so it can\u2019t be used by other tools. The sandbox and integration<\/a> are well worth checking out.<\/p>\n

So does GraphQL replace REST? Phil Sturgeon has a very useful post<\/a> summarising the philosophies of the two approaches, which he sees as complementary.<\/p>\n

\u201cHaving one GraphQL server act as a sort of data proxy, giving one entry point for mixed data, one Authentication scheme despite each REST API having its own “unique” approach to tokens, one HTTP call for clients – despite it hitting multiple actual REST APIs, etc., would be a damn powerful thing.\u201d<\/p>\n

\u201cIf you need a highly query-able API, expect an array of clients that need small and different data, and can restructure your data to be inexpensive to query, then GraphQL is likely to fit your needs.\u201d<\/p>\n

I strongly agree with Sturgeon on the docs and developer experience.<\/p>\n

\u201cAn alternative that is well documented, with a full specification, with a lovely marketing page, with an official reference implementation in JavaScript, and which avoids some of the tricky design choices REST forces you to make.\u201d<\/p>\n

Some of this stuff is fashion of course. REST has had a really good run, but is definitely looking less shiny these days. Developers like to try new things, and GraphQL’s timing is good. The companies adopting it are those that people want to emulate. But there are of course some dragons out there. In a followup Sturgeon points out that current caching models<\/a> don\u2019t map to GraphQL.<\/p>\n

\u201cDue to the way GraphQL operates as a query language POSTing against a single endpoint, HTTP is demoted to the role of a dumb tunnel, making network caching tools like Varnish, Squid, Fastly, etc. entirely useless.\u201d<\/p>\n

A web where Fastly doesn\u2019t work, where HTTP is a problem, sounds problematical.<\/p>\n

Kelly Sutton expands on the theme in a post Do We Need GraphQL?<\/a><\/p>\n

\u201cIn the world of GraphQL, HTTP is an unfortunate transport mechanism rather than something to be embraced. Rather than using the standard semantics, we ignore them completely by treating HTTP like a dumb pipe. For companies with enough resources, treating HTTP like a dumb pipe is feasible. You can develop GraphQL-aware caching layers and deploy that logic to edge nodes around the globe. But most of us are not Facebook, so we need to stick with the standards we\u2019ve got. This means using standards like HTTP to the fullest, so that we can be sure that our applications play nicely with vendors.\u201d<\/p>\n

But the benefits keep on twinkling. GraphQL introspection is interesting, as we grope towards self-documenting APIs with things like Swagger. Sashko Stubailo has some interesting ideas<\/a> here. Check out GraphiQL<\/a> – an inbrowser IDE for GraphQL.<\/p>\n

There are some intriguing new services emerging to take advantage of GraphQL like graph.cool<\/a> – which is effectively serverless or back end as a service GraphQL, which you\u2019d use if you take the Joe Emison view of serverless<\/a> not so much as Function as a Service (AWS Lambda) but as a model for building apps and services comprised of third party services such as Auth0, Algolia and Prerender.io. . Authory<\/a> seems to be doing exactly that<\/a> with its service for journalists wanting a single point of access for all their published content.Here we begin to edge into GraphQL not competing with REST so much as Firebase<\/a>.<\/p>\n

Scaphold<\/a> is moving forward with a similar model – focusing on simplifying GraphQL-first apps deployment to Amazon Web Services (AWS) cloud. Early customers include Visa. These services are like Parse or Firebase for GraphQL.<\/p>\n

In summary GraphQL maps pretty well to new API-driven models such as serverless. Michael Hunger from Neo4j feels REST is worth retiring. That said, technologies don’t die overnight. REST is hardly going to disappear overnight. But for a class of problems for high scale sites it\u2019s we\u2019re going to see significant adoption of GraphQL. The Google Trends chart at the top of the page shows growing interest in GraphQL and gRPC – GraphQL is blue. GraphQL maps to external consumption of APIs, with gRPC for internal. They\u2019re both clearly spiking in interest.<\/p>\n

Let me know if you\u2019re using or considering GraphQL. Certainly chatter is growing, and some very well respected engineers are choosing to run with it.<\/p>\n

 <\/p>\n

Google and Neo4J are clients.<\/p>\n","protected":false},"excerpt":{"rendered":"

  “We’re going GraphQL, we’re replacing everything with GraphQL” Sid Sijbrandij, GitLab founder and CEO GraphQL is an open source technology created by Facebook that is getting a fair bit of attention of late. It is set to make a major impact on how APIs are designed. As is so often the case with these<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[1],"tags":[],"class_list":["post-4474","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9wfjh-1aa","_links":{"self":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/4474","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/comments?post=4474"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/4474\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/media?parent=4474"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/categories?post=4474"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/tags?post=4474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}