Why Does Everyone Love GraphQL?

Why Does Everyone Love GraphQL?

In 2015, Facebook (that big social network company that also gave us React) released a new open-source data query language (QL) named GraphQL.

GraphQL became so popular that by the end of 2018 it detached from Facebook into its own foundation that is maintained by the Linux Foundation — a non-profit technology consortium founded in 2000.

But before GraphQL, there was REST , which stands for Re presentational S tate T ransfer. REST is a standard that defines a set of rules that developers needed to follow while creating any kind of web services. Web services that are based on these rules were termed to be RESTful. The reason why developers followed these rules is that it provided a kind of interoperability between different systems.

The most common types of Restful web services were those that allowed a client to send requests to the servers and the server would then respond back with some kind of data.

In simple terms, everything in REST revolved around the notion that data can be accessed through URLs. To get some data, you would need to send a GET request. To create or save some data, you would use the POST request. And to change or delete data, you would use the PUT and DELETE requests.

To create, read, update, and delete data has become one of the main operations of a developer. In fact, many tutorials ask you to create a TODO app in order to teach you how to do these things.

Here is a generic RESTful request that will GET you some data in the form of a JSON.

https://api.domain/marvelMovie/20

It would seem that REST works quite well, and a lot of developers still use it. Then why should one consider GraphQL and why has it become so popular?

In this post, I will try to answer this question by presenting some of its advantages over GraphQL, some cases where it can be updated to perform better, and why REST should now REST in Peace.

Tip: Turn components and APIs into Bit components, which can be easily discovered, shared and used from any project. It will help your team build faster and make it easy for users to find and use your components. Try it:

GraphQL

Before Facebook released it to the people as open-source, GraphQL was internally used by Facebook since 2012 as an alternative to the REST style of architecture.

But why GraphQL? How does it differ from REST?

In the previous section, we saw how a GET request in REST looks like. In that request, I mentioned that I need data of a particular marvelMovie whose id is 20.

But I did not mention what data I wanted. REST just assumed that I wanted to know everything about related to that movie and responded back with everything that it had.

GraphQL, on the other hand, gives us the ability to ask for specific data. This gives the client-side systems a greater amount of control over what information to request and receive.

It is a little difficult to do the same thing in RESTful architecture since the server side systems can only understand what data it has for each URL, and the client side system can only request for all the information related to a particular URL.

This is called overfetching .

At its worst, the developer’s application will have to go through a lot of data, sending multiple requests to the server, even if it requires only some of it.

GraphQL lets the client decide what data it needs and makes a single request to the server. This way, the network usage rate gets reduced like anything!

Here how a GraphQL query looks like for the same data that we requested in the previous section:

When the client application sends a request (called query in GraphQL) to the server, it gets compared with the entire GraphQL schema stored there, and then the server will fetch and send only that data which is requested by the client.

GraphQL does not care about the network layer or the payload format. Hell, it doesn’t even care about what programming language your app is written in. It only cares about the data.

The result of the above GraphQL query will look something like this in JSON format:

GraphQL — Plus Points

Here are some of the main advantages that one can get by using GraphQL in their app.

Declarative Data Fetching

In GraphQL’s, the client selects the data along with its entities with fields across relationships in just one query request. GraphQL gets to decide what fields are needs for its UI, and it also acts like a UI-driven data fetching. A client knows what data it needs while the server knows the structure of the data and how to resolve the data from a data source such as a database or an API.

Not just for React

GraphQL was created by Facebook, which is also the creator of React. This is one of the reasons why there is a lot of resources available to help you use GraphQL with React. But the actual reference implementation of GraphQL is written in JavaScript, so GraphQL can be used with other JavaScript based libraries and frameworks such as Vue, Angular, Express, Hapi, and Koa.

GraphQL — A Single Source Of Truth

The GraphQL’s schema is the place where all the data of the app is described. It is usually defined on the server. The server-side application provides the data and the client side asks for only part of it by performing queries and also modify the data with the help of mutations.

Schema Stitching

As the name suggests, schema stitching is the process of combining multiple GraphQL schemas into one big schema. A microservice is used to define a GraphQL schema, after which schema stitching can be used to “stitch” different schemas into one that is accessed by the client.

Access the Entire Schema

GraphQL also lets us access the entire GraphQL schema from the GraphQL API. This way, all the data stored in the API is made available to the developer, and they can easily generate (autogenerate) the documentation for the API.

GraphQL is Strongly Typed

If you are familiar with TypeScript, you would know that it is often refered to as a strongly typed language. A strongly typed language is one that has strict typing rule at compile time. This often means that the developer will have to take care of a few more errors and exceptions if they are not careful. Rather than this being a disadvantage, it means that the code will not produce any unpredictable results or perform any implicit type conversions at run time.

GraphQL is also a strongly typed query language as it is written in the expressive GraphQL Schema Definition Language. Apart from giving us predictable results, GraphQL can also be used for some supportive editor integrations such as auto-completion and validation.

No worries about Versioning

REST APIs are known to offer multiple versions of the same API. If you come across an API’s URL before, you would notice that it has v2 or v1 snuck inside it as shown below:

https://pokeapi.co/api/<strong>v2</strong>/ability/150/

This is usually because of changes in the structure or the data changes that can occur over time.

In GraphQL, you can simply deprecate the outdated API on a field level. This way, the same GraphQL API can be evolved to keep up with the changes in the structure and data, without resolving to versioning.

Room For Improvement

There are a few areas where GraphQL can be improved to perform better. Some of them are:

Complex Queries

A GraphQL query needs to be resolved with data on the server. It takes care of accessing the database. It also allows us to access multiple fields with just one query. But similar to REST, the fields still need to be retrieved from the database. So, if the client side application requests for too many nested fields in a single query, performance can take a hit. To quick fix to this is to add a maximum query depth, or prevent recursion and persistent queries to send inefficient requests to the server.

Rate Limiting

REST has a provision within itself that can limit the number of requests a client can make to the server. In GraphQL, implementing something similar is a little difficult.

Caching

In REST, data is accessed through URLs. So it is easy to cache the data using the URL as the identifier. But in GraphQL, each query sent by the client can be different (one query can ask for everything, while another only needs specific things like name or id). So a much more detailed cache needs to be implemented. But there are a few libraries out there that offer this kind of caching.

Conclusion

GraphQL is a great alternative to the previously popular REST architecture. While REST uses a URL to represent each data resource, it can often lead to inefficient query requests. Consider the example we saw at the beginning of this post. I want to access the details of a movie from the database, and it is identified with the help of an id. This movie has a lot of actors and many other details associated with it.

What if you only wanted the title of the movie?

You can’t do that in REST. But you can in GraphQL!

There are still places where REST is a great way to connect the client with the server. Today’s application is heavily dependent on data. And while some of them are better off with something flexible like GraphQL, others can work just as well with REST. Thanks for reading and please feel free to comment :+1: