Main advantages of GraphQL as an alternative to REST

GraphQL is based on a simple idea, moving the assembly of a request from the server to the client. The client sees the overall strongly-typed schema instead of multiple REST endpoints and he builds the query he wants.

My first REST based web application, SPAs for Single Page Applications as we are calling it lately, dates back to 2005. It was a time when REST requests and Rich Internet Applications (RIA) used to be called AJAX and were mostly used to transport XML. My first REST request in JSON was a few months later. How refreshing it was compared to the XML hell used at the moment! No more unnecessary parsing, unreadable schemas or dirty SOAP.

REST served us well and will still do for a long time. However, there are situations where it is not optimal and where GraphQL is much more convenient.

GraphQL objectives

GraphQL aims at providing self-documenting APIs to end users, using data from any source, to build production-ready applications.

API catalog

Speed of development

For example, if you need to change a property that is missing in REST, you have to change the server side code and reflect those changes on the client. While with GraphQL, you just declare a new property directly on the client where the data is used. Front-end developers don’t need to get in the server, assuming they have access to it. Junior and senior, they feels safe to use the data available. It makes them feel empowering. If a developer forgets to display an already available field from the model, he simply has to update his client.

Robustness of integration

An additional benefit is that it reduces the surface area of the applications both in term of potential bugs and security breaches. In case of any issue, the team can look at one place, where the schema is defined, and not hunt through every source base to look among multiple REST APIs that could be impacted.

Guarantees in Refactoring

Additional benefits

Not just for the WEB


At this point, most of the GraphQL APIs are published internally in companies but are not yet publicly exposed. GitHub has done it but it implies adding some mechanisms to ensure security and control any potential abuse. It lets people write semi-arbitrary queries against exposed data sets. For example, it is possible to define alerts when queries reach a certain threshold and are considered particularly slow.

Originally published at Adaltas.

Open Source consulting - Big Data, Data Science, Node.js