In a speech at the 2016 GraphQL Summit, Lee Byron of GraphQL/Facebook put forward a “Secret Master Plan” outlining his hopes for GraphQL, the growing API standard.

In an ideal world, he said, he hoped that GraphQL adoption would look something like this:

• 1–3 months – Hobbyists and personal projects
• 6 months – Implemented in 3+ languages
• 9–12 months – New startups and small companies
• 1.5–2 years – Medium sized companies and products
• 2 years – Implemented in 10+ languages (actually took ~3 months)
• 2–4 years – Large companies and tech giants
• 4–5 years – Ubiquity!

If we assume that this plan was written when GraphQL went open source in 2015, rather than when it was created in 2012, it’s eerie just how “on track” the timeline is.

Right now, we’re in the middle of the large companies and tech giants phase — GitHub, Pinterest, Intuit, Coursera and Shopify all use GraphQL in some environment or another. This means that there are two or three years to go until its creators hope that GraphQL will be omnipresent.

In this post we’ll be looking at how realistic that “prediction” could turn out to be. We’ll us use the term loosely, as it’s clear that Byron never intended this to be an official product roadmap.

GraphQL 101

Before it’s possible to determine whether or not something is “the next big thing”, you have to know exactly what the thing is. If you’re reading this blog then there’s a good chance you already know that, but let’s err on the side of caution. GraphQL is an API standard, a query language that was open-sourced in 2015 after being used only for internal use at Facebook before that.

Because of its relative newness, there are still plenty of misconceptions about GraphQL. One of the biggest, highlighted by Graphcool developer Nikolas Burk at our Platform Summit, is what it does at its most basic level: “It doesn’t have anything to do with databases; it’s an API technology, not a database technology.”

He also outlined a few advantages that GraphQL APIs have over their REST equivalents:

REST API…

• Endpoints that return fixed data structures
• Multiple GET requests required
• Pulling more information than necessary

…vs GraphQL

• Single endpoint
• Returns flexible data structures
• Query precisely describes data requirements

It’s easy to see cases in which this could be useful, e.g. avoiding the unnecessary strain placed on user data plans by swathes of excess data.

It’s important to note, however, that REST and GraphQL aren’t exactly in direct competition. Phil Sturgeon of Smashing Magazine argues that GraphQL can’t even be considered a true replacement for REST because you can use both at the same time and one is a query language, spec and collection of tools while they other is an architectural concept.

In fact, even the SOAP vs REST debate seems to have eased in recent years with more emphasis being placed on picking formats based on individual use cases. That should certainly provide some comfort to developers who have invested a lot of time and effort in REST, which while supercedeing SOAP may never have killed it off in the way that so many people predicted.

Adoption of GraphQL

Right now, trying to find statistics on the adoption of GraphQL is a challenge. We certainly know the names of the bigger tech companies that are using the service, but there’s not much out there on the exact number of APIs built around GraphQL.

For example, let’s turn to the ProgrammableWeb. While you can identify APIs as being GraphQL when listing them on ProgrammableWeb’s API directory, there’s currently no GraphQL category as there is with REST. The main GraphQL website lists 114 organisations, of varying sizes, using it in their stack but this is limited to those who have added a pull request to the site manually. GitHub is also home to various GraphQL resources, such as APIs-guru’s list of 30+ GraphQL APIs and chentsulin’s GraphQL hub that includes information on everything from GraphQL meetups to libraries and tutorials. Once again, however, very little in the way of hard numbers.

Drupal provides some usage statistics for GraphQL but, again, this is limited to Drupal websites with the Update Status module. At the time of writing that number (i.e. of Drupal sites using GraphQL) stands at 212, with particularly rapid growth in the final months of 2017. Elsewhere, however, it’s highly likely that there are already thousands of companies now using GraphQL to some extent — making billions of API calls a day — in their stack.

Much of this growth is powered by the rise of GraphQL tooling services. Solutions like Apollo and Graphcool provide a universal GraphQL API over existing backends and frameworks to develop and deploy serverless GraphQL backends respectively. It’s true that there’s still a learning curve associated with using GraphQL, but tools like this make implementation much easier even if you’re currently using REST or SOAP.

What Next For GraphQL?

Traditionally in tech, “the next big thing” is defined by what startups are using. Slack, for example, emerged at a time when just about every startup and small business seemed eager to move away from the daily barrage of emails while still keeping tabs on what was going on internally. With its freemium model, Slack took off pretty much immediately.

Things are a little different in the API space, in that smaller companies are often influenced by what the “big boys” in tech are doing…not least because they may need to understand it in order to plug into those APIs. As a result, the ongoing adoption of GraphQL by big companies is a step towards ubiquity.

Microsoft, for example, has a GraphQL demo for their Graph API. How it works is it takes in an OData API description, parses it, creates a GraphQL schema, and generates the necessary resolvers.

“Qualitatively, we’ve seen that the GraphQL version of our API really helps people understand what resources are available, and what the structure looks like.” –
Dmitry Pimenov, Program Manager, Microsoft Graph

While there may be performance bottlenecks on wrapping an existing REST API, GraphQL offers an unparalleled developer experience for the enterprise. It’s clear that Facebook themselves have sights set on enterprise GraphQL adoption, given that they have a starter kit specifically designed for large organizations that goes as far as offering in-house presentations and Q&A sessions from GraphQL experts.

Beyond The Secret Master Plan

From smart homes to using services like IFTTT and Zapier to cultivate a personal brand, the general public is taking more and more of an interest in APIs than ever before. Combine this with the expectation of continued growth from GraphQL and we may well have something of a perfect storm that could see GraphQL being widely adopted.

That doesn’t even begin to talk about the considerable influence of its creators, “2 billion users and counting” Facebook. With the flexibility and client focus offered by GraphQL, it’s not impossible to imagine it as the first API language learned by newbies to the development scene.

Previously, some have expressed concerns about Facebook’s attempts to patent GraphQL although many of these fears have since been allayed by relicensing. That represents another area in which GraphQL is doing well – Byron and his team appear, and granted it is still early days, to be extremely responsive to feedback from the community.

Final Thoughts

To put it in simple terms, it isn’t difficult to imagine that 4–5 year plan we mentioned in the introduction playing out as Byron hoped.

While the architecture, language etc. you build your API will always depend on what you need it to do, GraphQL offers all sorts of advantages — great tooling, a ton of flexibility and less time spent writing API documentation to name a few — that are difficult to ignore.

In APIs, as in all of tech, these things are rarely as simple as “X is in, Y is out.” But one thing is for sure: GraphQL seems to have what it takes to continue to make waves: it already has an annual summit, plus it has some serious clout thanks to its association with Facebook and “household name” early adopters like Twitter, GitHub and Shopify.

While GraphQL may not sound the death knell for REST, it contains the right set of ingredients to be around for a good long while.