GraphQL, the future of APIs

Facebook may not be the favorite company of the open web community, for some good reasons. But when it comes to open source, most developers take advantage of their tools, libraries, and frameworks in one way or another. In particular, Javascript (Node.js) and PHP have advanced by leaps and bounds largely thanks to Facebook’s contributions. Although, one such technology that’s often overlooked is GraphQL, which, for many, has real potential to replace the infrastructure of the connected web, the REST APIs.

Drawbacks of REST APIs

REST is good, that is until it becomes a hairball.

For simple, single-purpose APIs like Flickr’s, it does the job, but as the Facebook’s Graph API documentation shows, its flat structure becomes unmanageable with multi-function, multivariate systems.

Even this formatted view of REST APIs is overwhelmingly complex.

Nevertheless, REST’s design with primitive pagination and no support for slicing make it a no-go for complex queries. For example, this GraphQL example below:

where we query movie heroes with their name and the names of the first of two of their friends would take multiple REST API calls to accomplish. More queries only add up to the unreadability of REST’s already ugly syntax.

JSON to the rescue

When JSON first came out, in Steve Jobs’ saying, it was a glass of ice water to all the developers out there in the inter-connected web services hell with SOAP and co.

GraphQL is heavily inspired by JSON’s success, as it uses a similar simple format to define the APIs. Moreover, for the very first time, it encompasses:

  • queries (the equivalent of SELECT in SQL),
  • mutation (the equivalent of INSERT/UPDATE in SQL)
  • and schema.

in a single format, which makes it uniquely singular to define and use web services.

GraphQL is still work-in-progress for the most part, but it is a good start. The website claims it has already been explored or used by Yelp, Intuit, Pinterest and Coursera. However, its success will only depend on the indie developers who can up the ante with new tools, implementations, and specs around current drafts.


  1. fun post, thanks for writing this up!

    i’ll happily grant you the technical arguments…but even so, we’ve been here before, over and over: JSONPath, SPARQL, LINQ, YQL, XSLT, and even Facebook’s own dead last attempt, FQL. i’ve done deep dives into YQL, Azure Tables/LINQ, SimpleDB, and Facebook’s own Data Store API, one of their earliest. i’ve even developed one of these languages myself. i’m not proud.

    they may all be technically better in various ways, but none of them have caught on broadly in the way that REST has. that may be “worse is better” at work. i guess we’ll see what the future brings.

    in my own experience with Facebook’s Graph API in granary and Bridgy, the main limiting factor hasn’t been the URL-path-and-query-params interface, but instead their sprawling, complicated, inconsistent data model. i haven’t needed deeply rich or complex querying, though.


    1. Thanks Brian! Granary and Bridgy are both very interesting. I’ll take a deeper look and see if we can use them in our upcoming projects.

      Social APIs are not only inconsistent, but they’re also unreliable, they add and remove features too frequently. We once did Kontextful, a tool that aggregates one’s Facebook Groups and lets you share web links in one click with relevant ones (without you manually choosing which group to share) – but a few months later, the privileges it depended on, were cut off… Good thing it was a fun & free time project, an opportunity for me to play with k-clustering on social APIs, not a business, but the experience was not tasteful.

      As for the technologies you mentioned, I find LINQ actually pretty interesting, since it’s language-integrated. And I can only hope GraphQL’s fate won’t be like any other on that list.

    2. Also, I’d definitely recommend you to take another look at GraphQL, as it’s pretty different from YQL and FQL (SQL replica to query proprietary data silos) and LINQ (a promising language integrated SQL replica) — the others I had never heard of. GraphQL is, for the first time, a way to bridge schema, queries and updates (mutations) in a single format. I’m working on an open source project that will make it more clear. So, more on that soon.

Leave a Reply