You have likely heard of GraphQL but may not be quite sure how and if it’s different from REST. Well, you’re in luck! Today, we are going to go through some essentials on how GraphQL is benefiting the developing community over REST.
A Look at GraphQL
Most people think that GraphQL a database technology, but this isn’t accurate. GraphQL is a query language API, and as many of you likely know, most of the applications today have their data hosted on a remote server in a database. The API only has to give an interface to put-away information that meets application requirements.
GraphQL is an alternate option to build APIs in REST. Facebook developed it as an internal technology for their versatile applications, and later, publicly released it as open-source. Since then, the software development community has utilized it as one of the favourite technology stacks for developing web services.
As a query language, GraphQL defines specifications of how a client application can request the needed data from a remote server. As a result, the server application returns a response to the requested client query. The exciting thing to notice here is that the client application can also query exactly what it needs, without relying on the server-side application to define a query.
Let’s dive deeper and analyze the core differences between REST and GraphQL.
Fetching Remote Data
Assume that a mobile or web app wants to access data from a server that displays the blog author information. The app is supposed to display the author’s name, the blog posts written by the author, and the three most recent blog topics written by him/her. Let’s give an abstract level review on how to fetch this data in REST vs GraphQL.
Here is the pictorial representation of REST vs GraphQL API:
REST Request
In REST, an API endpoint is called to request the data that the client app needs and the server returns the response based on the requested query. When someone uses REST API, they would first have an endpoint which could be https://www.mobilelive.ca/blog/author/<author-id>, this endpoint would fetch the author’s information. Now another REST endpoint is needed to access the blog posts https://www.mobilelive.ca/blog/author/<author-id>/posts, and finally, you would need yet another endpoint to get the blog topics https://www.mobilelive.ca/blog/author/<some-id>/topics. Now here, you will notice two issues:
Problem 1: Multiple roundtrips with REST
As you would have noticed, there are multiple roundtrips that one should make while utilizing REST to get the information that a client application needs. One has to add additional endpoints if the information is extended.
Problem 2: Over-fetching and Under-fetching Problems with REST
Frequently with REST, one will wind up with unnecessary information at a specific stage. For instance, when calling the blog/author/<author-id> endpoint, the client application will get all the information related to the author’s profile. It could even get back other information like date created, date updated, age, and gender. But what the client application required was the only author name. It’s a case of over-fetching in REST. On account of under-getting, one can see here that the call to blog/author/<author-id> was not adequate to recover what the client app was searching for. The client app needed to make a separate call to another endpoint blog/author/<author-id>/posts to get the last three posts composed by the author.
GraphQL Query Request
Now let’s think about what happens in GraphQL. You think of a query to request what you need, and you get back precisely the data you asked for. There are no full circle trips to remote servers to bring information to GraphQL.We only go for the fields that we need from the server to the client app.
Look again at the above example, where we were searching for the author’s information through a specific ID, the blog posts written by the author, and the three most recent blog topics. The requested query in GraphQL is organized to get the information precisely.
The server will provide a JSON response that has been specifically requested. It has returned the author’s name, the posts composed by them, and the previous three topics created by the author – that’s it. There were no multiple round trips to the server, no over-fetching, and no under-fetching of data. Let’s have a quick look at the graphical representation of the differences between the two.
Quick Product Development on the Frontend
During the consumption of REST APIs, frontend development groups have to wait a certain amount of time for the backend group to finish writing these APIs for the client app to fetch and post the data. Often the frontend team is the ones who become the victim for this slowness in the development lifecycle because their hands are tied until the backend developers finish developing the REST APIs. The overall development process is solely reliant on the REST API development and delivery time. The GraphQL lifecycle provides a very different and more efficient approach where both frontend and backend developers can work in parallel without obstructing the overall development process.
Is GraphQL an Underrated Query Language?
If someone is new to GraphQL, it will be challenging for them to set it up as its ecosystem and processes are still advancing and maturing. But once one has a good understanding of GraphQL, they can send simple string queries from the client application to fetch data from remote server-side applications to do the required job. On top of that, libraries such as Apollo, give ease to caching and API development. It handles the scenarios about caching on its own, without a need for custom code to enable it. On the other hand, file or image uploading in GraphQL is still not tremendously evolved, and one needs a REST API to better perform this job.
Takeaway
Both GraphQL and REST API development lifecycle approaches are useful depending on the need, and both have their advantages and disadvantages. GraphQL is exponentially gaining popularity, mainly because of its “no over and under-fetching” ability. It provides more efficient collaboration mechanisms for the client-side and is proving to be a great and powerful tool, especially as the software industry is adopting an agile framework. In short, GraphQL is a tool to achieve specific query oriented goals; however, it’s not a solution for all the API related challenges and certainly not a replacement for REST.
