GraphQL is gaining popularity because of its ability to develop APIs more efficiently, powerful, and flexible as compared to REST.
We all know REST is the traditional method to work with APIs but after the launch of GraphQL in 2015 it has really taken off with developers.
GraphQL is the query language for your API which allows you to get exactly the data you need (no more, no less) whenever you need it. It was developed by Facebook & now it's maintained by a large open-source community.
GraphQL Advantages
Let's take a look at an example: Suppose we want to make a blog app & we want to display the name, title, followers of a specific user. With REST API, we might have to send the request to multiple endpoints in order to fulfill our data needs.
for example:
/users/{id}/name
/users/{id}/posts/title
/users/{id}/followers
With REST API you will end up sending 3 requests to the server. In the case of GraphQL, we just have to send a single query to the GraphQL server & then the server will respond with JSON data.
query {
User {
name
posts {
title
comments {
comment
}
}
followers {
name
}
}
}
and we will get a response like this:
{
"data":
{
"user": {
"name": "John Doe",
"posts": [
{
"title": "How to fetch data from an API",
"comments": [
{
"comment": "Great post."
}
]
},
{
"title": "How to build REST API with Node.js",
"comments": [
{
"comment": "So neat & precisely written."
}
]
}
]
"followers": [
{
"name": "Ben Smith"
}
]
}
}
}
No over and under-fetching
Over-fetching means the client downloads more data than required & Under-fetching means that the specific endpoint doesn't provide enough data which the client needs.
In REST API each endpoint has a fixed data structure which means most of the time we fetch more data than we actually need or we need to call multiple endpoints to fulfill our data needs.
In the case of GraphQL, it allows clients to request data from several resources with a single request which solves the problem of overfetching & underfetching.
Speeds up the development process
Suppose you're working on a project whose product requirements change suddenly & the worst case happens: the REST API requires a new endpoint. Now In this case front-end developer team will get blocked on their work & will be entirely dependent on the backend developer team.
GraphQL makes front-end developers' lives easier because the data consumed on the client is no longer coupled to an endpoint's resource which speeds up the development process for both frontend & backend developer teams.
Comparing GraphQL with REST
Popularity
GraphQL is gaining popularity exponentially over the last few years.
According to the State of API Integration Report 2021,
75% of respondents expect GraphQL to be the dominant future query language for APIs. For reference, in 2020 only 40% said GraphQL would be the predominant approach in the future
But REST remains the most popular among the respondents of API report 2021 as they believe GraphQL is lagging behind industry adoption.
Usability
It's simple to get the precise data you need from your database using GraphQL's queries. This makes data consumption much easier as you get predictable results.
Compared to REST It returns all the data available from the specific endpoint. This can lead to data dumps where the client has to download unnecessary data which is not used.
Arguably GraphQL is easier to use as compared to REST.
Performance
Customized queries in GraphQL improve efficiency in a variety of ways, from lowering the number of API requests to ensuring the proper amount of data is returned.
But wait… REST API might be better when it comes to performance
To return cached results quicker, REST APIs use the built-in HTTP caching mechanism which can perform better in circumstances where caching is required to fast-track API calls. Caching is also available in GraphQL, but not to the same extent as it is in REST.
Pros and Cons
GraphQL pros
Provides consistent, uniform data.
Eliminates over-fetching & under-fetching.
Speeds up the development process
GraphQL cons
Lacks built-in caching.
Complicated error handling.
Lacks industry adoption & support.
REST API pros
Supports different data formats (Html, JSON, etc.)
Popular & has great adoption & support from the community.
REST API cons
Multiple requests to the server to fetch all the data needed.
No specific method for structuring API.
Conclusion
I am not an API expert but I find it really interesting & fascinating to work with GraphQL. If you're looking for an answer to which one is better you probably are at the wrong place. It really depends on every application's use-cases to decide which API form is better.
I suggest just trying experimenting with them both & see if that fits your development workflow.
Comment down below If you got an opinion that you want to share.
I hope you liked the article.
Keep learning!
Top comments (9)
GraphQL has a lot of drawbacks in comparison to REST ranging from bloated payload to security and scalability concerns. But if one uses GraphQL on the edge of infrastructure, e.g. to connect RESTful microservices, it truly shines. Hence those two are not rivals, they compliment one another quite nicely ☺️
Maybe I need some experience with GraphQL to better understand the comparison, but I would agree on that it cannot or should not replace REST APIs. These are just two different options and surely not the only ones!
Also you will not always have the possibility to decide which one you can use, because if you are consuming endpoints (which are not developed by yourself), you will have to choose from what you get.
Agreed! They totally complete each other. My approach is to write every specific API using REST and then connect them using GraphQL, also do all complicated and process hungry calculations on the GraphQL side, a k.a use GraphQL as a BFF (backend for frontend). It has worked nicely in my last two jobs
100% agreed!
You actually don't have and should not choose between GraphQL and REST. They solve different problems and work best if you combine them. I'm the creator of WunderGraph, a framework that does exactly this, combine the strengths of both. We leverage the flexibility and type-safety of GraphQL and the performance and security aspects of REST. It's built in a way that feels like you're using "just" GraphQL with all it's bells and whistles but you're actually creating REST apis behind the scene. I'd love to hear your feedback. Here's a link: wundergraph.com
Well said. It's not an either/or situation, a lot of - especially more enterprise usage - implementations would not benefit from a purely GraphQL data acquisition model.
There is a method for structuring API's called Open API Specification. API Gateway is also a great tool for creating a reverse proxy as well as aggregated requests. I really like what @valeriavg said in their comment, which is spot on. @mehmehsloth keep putting out content. It takes a lot of dedication to do so!
I don't agree with the first example, why would you not write an endpoint that returns all 3 of these sets of data if you knew it's what you required?
I believe this is misleading, to make GraphQL look more convenient when actually you can achieve the same extremely easily in REST with good planning.
thank you