Why you should try GraphQL?

GraphQL started at Facebook back in 2012, it was developed internally before being released as open-source in 2015. In 2018 the project was moved to the newly created GraphQL Foundation, hosted by the Linux foundation. GraphQL creator Lee Byron has stated his aim is to make it ubiquitous across web platforms. Let's look at how plausible that perspective is.

A bit of theory

GraphQL is a query language for APIs, its main advantage is allowing clients to define exactly what type of data is required. Developers create a schema that contains all the data clients can query through the service. This schema contains object types that determine the object you can request and the types it has. The schema is the basis all queries get checked against and then, after being validated, executed. Each field in the schema is attached to a function, called a resolver, which gets called to produce the values when a query is executed.

A bit of practice

Let’s check out how it actually works by looking at a simple example like a forum, blog or social media. In our example let’s say users have four properties: username, email, location and ID and can create posts with titles. Now if you need to create a profile component that only shows the username and ID, you don't need the user’s email and location. With REST and other web service architectures, the API returns all user data and there’s no way to request specifically what you need without fetching unnecessary data. Doesn't sound like a big problem? Just look at Facebook accounts and how many variables they have and you’ll easily get why they started developing GraphQL.

GraphQL allows you to request exactly the parameters you want and the API responds with only the data you requested. It also does this via a single endpoint that handles all the client’s requests. That was just a basic query. One of the advantages of GraphQL is the ability to nest queries so it can be expanded to fetch a number of variables.

Let’s go back to the above-mentioned example of a blog/forum/social media API. What if your profile component needs to be a bit more complex? We’ll make a query that requests some basic user info as well as post titles for that particular user so that the profile provides a glimpse of the user’s activity as well as basic information.

Why development teams are adopting GraphQL?

One of the surveys directed to a variety of companies having experience with GraphQL asked their CTOs and lead developers why they decided to pivot to GraphQL. The survey identified six main benefits (Development Velocity, Modularity, Scalability, Performance, Reliability, Security) and asked responders how strongly they would agree/disagree with the following statements:

We were able to speed up our development using GraphQL
We were able to scale our projects faster with GraphQL
It was easier to unify our APIs (e.g., Microservices, legacy endpoints, third-party services, etc.)
There has been an increase in performance using GraphQL
Our architecture is more stable, with decreased downtime, and fewer errors

The results are:

Source: Novvum @medium

The interpretation of the survey's results was summed up closed in the table below. The most important thought is that GraphQL managed to provide what teams were looking for that small to medium as well as large enterprise teams.

Team size	What they wanted to achieve	What they've achived
50-100 & 100+ devs	Faster development speed, better scalability, better modularity	Faster development, better scalability
10-50 devs	Better modularity, higher performance	Faster development, better infrastructure
up to 10 devs	Faster development, better modularity	Faster development, better scalability

Simple and flexible

GraphQL not only straightforward, but it's also extremely adaptable. GraphQL is client-driven and it’s creators emphasize they were focused on the needs of the client, not the server. That’s also why graphQL is so flexible so that it’s as easy as possible to use for clients. You can use GraphQL with:

Python,
React
Java,
C++,
PHP,

and a number of others as it’s meant to be a one size fits all solution that retrieves data regardless of the service, platform, or coding language. Can it become widely used across all platforms? Time will tell, but it certainly has all the tools for that.