GraphQL is incredibly powerful — so powerful, in fact, that it is used by corporations such as Facebook to drive their large, complex social systems for billions of users. Despite this, the language is still relatively nascent, and its usage has yet to reach the dizzying heights that those languages it replaces and augments occupy.

In this piece, we’ll discover what GraphQL is, and what makes it so powerful. We’ll give you five compelling reasons to adopt it as part of your system and ecosystem, and highlight some public use cases that demonstrate the success of such adoption and integration.

What is GraphQL?

GraphQL

GraphQL is an application layer query language. What this means is that GraphQL is designed to interpret a string from a server or client and return that data in an understandable, stable, and predictable format. As the official website for GraphQL puts it, “Describe your data, ask for what you want, get predictable results.”

GraphQL does this via simple, plain to understand requests and statements. A simple example from the official website highlights this simplicity perfectly. This is a valid descriptor within GraphQL:

type Project {
  name: String
  tagline: String
  contributors: [User]
}

Which, when paired with an effective and simple request:

{
  project(name: "GraphQL") {
    tagline
  }
}

Returns a clean, easy, and simple result:

{
  "project": {
    "tagline": "A query language for APIs"
  }
}

The simplicity and power behind the language comes from its chief architects. GraphQL is principally an effort from Facebook, with a variety of additional contibutors dedicating their efforts to boost efficency.

GraphQL came from the result of Facebook’s transition away from HTML5 applications on mobile to supporting more robust, native applications. As the need for a stronger backend and easier universal interface presented itself, GraphQL quickly emerged as the language of choice.

With all this said, what makes GraphQL so powerful?

1 – More Elegant Data Retrieval

GraphQL is all about simplicity — and with that simplicity comes a more elegant methodology and experience concerning data retrieval. Because data is collected under a common endpoint or call that is variable concerning the type of data and request as stated in the initial call, several huge benefits are intrinsic to the call system.

First and foremost, using GraphQL eliminates ad hoc endpoints and roundtrip object retrievals. Imagine you were a delivery driver looking at a map of where to deliver a package. On that map, you have fifteen possible entry points to streets near the street you need to get to — each with their own speed limits, limitations of cargo weight, and allowed vehicle type.

The complexity incurred in this situation is absolutely incredible, so much so that it would delay delivery. Now imagine the same situation, but with only a single street and will well-defined, commonly known rules — that’s what GraphQL can provide.

2 – More Backend Stability

With simplicity comes stability — this is a basic fact of life. The more simple a process is, the less likely there are to be faults in the planning, construction, execution, and continued operation over time. GraphQL makes queries more simple and elegant — and as a result, improves the stability of the entire process.

How GraphQL does this is quite complex, but there’s one methodology in particular that is worth mentioning. Because data is delivered in a structured, defined way independent on the client request (as the rules are dictated by GraphQL itself, not the application per se), data can be manipulated, changed, and altered in the backend code base without directly requiring changes in how the client functions.

In the traditional server-client relationship, this is simply not possible — the data is available, queryable, and usable, but the format and method are dictated largely by the client. As long as the general request fits into a standard methodology as dictated by the language or documentation, that data is delivered successfully. Change how the database works, however, or update the application independent of legacy support systems, and you have a “broken” application.

This is not a problem with GraphQL. The entry point defined by GraphQL is almost like a translatable layer — the structure of request is dictated by the server, and then routed to the necessary resources and systems by the language path itself. Accordingly, an application backend can be overhauled without necessitating a complete restructuring of the client application or the common call method, as the methodology is controlled directly by the server in the first place.

3 – Better Query Efficiency

GraphQL unifies data that would otherwise require multiple endpoints, or in the worst case scenario ad hoc endpoints and complex repeat retrievals, and gives the requester a single, simple entry point.

Because data is defined on the server with a graph-based scheme, data can be delivered as a package rather than through multiple calls. For instance, the following code for a content and comment query would have a single endpoint in GraphQL:

{
  latestPost {
    _id,
    title,
    content,
    author {
      name
    },
    comments {
      content,
      author {
        name
      }
    }
  }
}

In traditional API query languages, this would take at least 8 calls, and would have to point to specific endpoints to differentiate the content of the post itself and the comment content.

This doesn’t just increase efficiency of data delivery, either — it fundamentally decreases the amount of resources required for each data request. Furthermore, retrieval constraints are declared with a declarative-hierarchical query to a single endpoint, reducing the call data demands less for the client.

The biggest net benefit of this entire process is, of course, a fundamental restructuring of the relationship between the client and the server. In GraphQL, the server publishes clear and explicit rules specific to the application, and the client requests that language with common data queries. Simply said — developers are able to impose data restrictions more naturally and with less impact on the consumer.

4 – GraphQL Is a Specification

Perhaps one of the greatest benefits of GraphQL is that the overhead for adoption is low specifically due to its status as a specification. While there are always new tools on the market, many developers shy away from adopting these solutions because they’re “too involved” or “too invested” in their REST architecture.

As a specification, GraphQL is a wrapper that can be defined — you don’t have to replace a REST system. This means that developers can reap the entirety of the benefits of GraphQL while ignoring the cost overhead of its incorporation.

A huge benefit of this GraphQL wrapping is also in how it changes the relationship between data and the systems that require said data. Data in GraphQL isn’t limited by the language or the datatype, and is instead limited by the server descriptions as defined to the client (so, in effect, not a limitation at all). Data wrapped in GraphQL, regardless of the underlying language or system, can be shared between variations in standard API schemas and the wide range of languages which create them.

More specifically, this also means that GraphQL is fundamentally compatible with anything that REST-centric APIs are compatible with — therefore, the entry point for both GraphQL and its interactiveness with REST dependent systems is relatively low.

5 – GraphQL Improves Understanding and Organization

Perhaps the biggest benefit of implementing GraphQL is one of importance to the API ecosystem as a whole — 99% of the time, an API can be organized into a simple and understandable graph schema, and doing so forces you to better organize and understand your data, the flow of that data, and the inefficiencies and errors in that system.

While this has a net benefit to the developer, it has huge positive implications for the development ecosystem as a whole. Because GraphQL attaches types to data, types errors between applications and your server and GraphQL compliant applications to other applications start to disappear.

What we’re talking about here is a type of “universal translator”, providing data translation between different services while removing the bottleneck typically encountered, Furthermore, this removes pressure towards application developers to ensure compatibility and mutations.

A huge benefit to developers and a more positive interaction in the ecosystem — what’s not to love?

Who Uses It

Because GraphQL is extremely powerful, it’s been used by several providers who need stable readability with quick speed and indexing. Most of the use cases for GraphQL are therefore those who require high data throughput with ease of sorting, which is certainly represented clearly by its most high profile users.

Hudl sports data analytics improved in part to GraphQL

One example of how powerful GraphQL is when it comes to handling high data throughput in a relational matter is Hudl, a sports video analytics provider. Essentially, Hudl takes video of sporting events, practices, and other situations and provides professional feedback for each player and a general overview incorporating this feedback.

Accordingly, the data processed by Hudl is strictly relational — unlike other solutions, the data being handled isn’t simple one-to-one relational data. Each player belongs to a team, but each player has their own data which is attached to specific activities, skills, and approaches.

In a traditional query language, comparing and contrasting these hugely discrepant data points between each player and then each team would require a massive amount of data combination, or at the very least, a huge range of calls being called multiple times to each server system each second.

With GraphQL, each item is described clearly, and requested specifically by an application. GraphQL allows for a small range of endpoints that provide this data in a consumable, easily understandable method. This also means that the data generated by Hudl isn’t strictly tied to their application, and their application alone — since it’s described directly, the data can be imported into team planning applications or health tracking applications for tracking of physical health, performance in certain environments, and other such relational queries.

This interactiveness can be seen in another application of GraphQL, AlphaSights. AlphaSights can be seen as a “middle man” of sorts, but one of incredible power — connecting clients with experts and the services that they can provide. While this seems simple on its face value, the underlying data is very valuable, not just to AlphaSights, but to those they provide this data to.

The engineers at AlphaSights stated themselves the huge value of integrating GraphQL into their system to reduce complexity and improve exchange of data:

“GraphQL gave us one way in, and one way out. All data was resolved through one object, Graph::QueryType. The presence of only one object provided a much easier learning curve for new developers looking at the code base, and the higher level concepts each have their own resolver making it easy to narrow down what each term meant right down to the database level. … By making the server to consumer contract flexible, we get the benefit of much more agile teams, and less debate on how and if the consumer receives that data. We have also found that maintaining the services is much easier. There are no “v2” routes to be added, and the type system allows the consumer to easily discover updates. We have also taken advantage of “GraphApi::Schema.middleware” to monitor which attributes are being used, and help identify legacy types/fields that we can remove, which we are going to open source in the future.”

Being able to not only provide data in an easy format, but to make that data easily interactable and digestible by novice developers is a huge benefit, and makes data generated truly extensible.

GraphQL isn’t only for huge complex databases, either — it can easily be used to create relatively simple databases with greater efficiency. A great example of this is Beek.io. It’s fundamentally a social network, albeit a niche one, focusing on books and those who love them. While the database itself is relatively simple — author, name, genre, etc. — the way this content is handled is supremely simplified under GraphQL.

By simplifying calls to a single entry point, you prevent different endpoints from providing the same data in different ways, and increase the understandability of the data that is delivered. Because of this, while Beek.io is a rather simple incarnation of the social media sphere, it is extremely responsive, and delivers data in a way that book lovers can actually use to better their reading library (and perhaps their friends list).

Conclusion: Assess

While GraphQL is obviously powerful, there are some arguments against it — chiefly that it’s still in its infancy. API Evangelist sees GraphQL as a way around “properly getting to know your API resources,” doubting whether the majority of non-technical API consumers will find it useful. Others have expressed that an organization shouldn’t integrate GraphQL simply because a behemoth like Facebook or Github has a GraphQL API.

ThoughtWork’s 2016 Technology Radar, which reaches action verdicts for emerging Techniques, Tools, Platforms, and Languages, labels GraphQL as ASSESS. Whether or not to adopt GraphQL should at the very least be assessed; For as we’ve seen through this article, it can help ensure data is efficiently generated and accessed, and can make the applications powered by the server that much more powerful and extensive.