JoinDownload

What is GraphQL and How it differs from REST?

10 Min Read

Vyom Srivastava

What is GraphQL?

GraphQL was designed by Facebook and the main goal behind designing GraphQL was to make the query smarter. In GraphQL you can make selective endpoints like you don’t have dumb endpoints you can pick up selective information from that endpoint using GraphQL. GraphQL can dig a little bit deeper into your API endpoints and can pick selective information from it. In simple words when your REST API becomes smarter that’s your GraphQL. The word graph here in the GraphQL simply means that our queries are now able to crawl into the REST API and pick up the selective information. So that’s why the graph came up and the QL you already know means queried language.

What is REST API?

REST stands for Representational State Transfer. It is an industry known and accepted architectural style that became very popular in building loosely coupled web applications over the internet. The most important you need to know about the REST API is that they are all about communication. With the REST API, you have your web app or a web page that is communicating with a cloud-based server via REST API. It is fundamental to your cloud application. Also, you may have heard the term restful web-service. So it is a web-service that uses REST APIs to communicate. It was the dissertation of Roy fielding and it is basically his creation.

Since the invention of the internet, we have been using different applications on web pages to get the data for various resources. However, have you ever thought about where this data comes from, well it’s the server from where we get the data? Sometimes people think that GraphQL is a database technology but that is something that is not true. This is a very big misconception because GraphQL is a query language and it is used for APIs, not for databases. GraphQL is used by backend developers to design their APIs.

Limitations of REST API

One of the limitations of REST API is that the ability to maintain a state in REST can be lost. Like within sessions The main problem with this is that it can be more difficult for newbies developers to use that technology. Also, the implementations are quite poor, overly complex data structures and I’m talking about both input and output. The most important limitation is its inability to PUT, PATCH, and POST from a web browser when testing. The other major limitation of REST API is its nature as client-server based. And the other one has named the use of a uniform interface.

Over Fetching and Under Fetching issues in REST API

The most common issue in REST APIs is Over fetching and Under Fetching of data. Because since REST provides static endpoints which you cannot change the particular response based on your need and you’ll get too much amount of information because you don’t need that many information here on the other hand in GraphQL we can query whatever data you want if you need currency information you can even provide currencies and you can get the name of the currency as well. So based on the type of information you require you can get or change your input based on which are responses resolved. However, in REST, you’ll have to have a separate REST endpoint which can have a custom response so that’s where the over fetching or under fetching comes in place. Now the question is what if somebody doesn’t require currency instead he requires some other information. Then you’ll have created one more REST endpoint in that case. So that’s the reason for the over fetching and under fetching issue in the REST API.

If we take an example, let me just tell you we want to fetch certain information from our website. For example, let’s try to fetch the age, name, gender, height, and highest score of the top 5 players that played in 2005 world cup. Yes it can be done, we can fetch the queries but now assume that the data that you’ll be fetching, it’ll be surely an overfetch. You’ll be fetching a lot of information and then we’ll be knit picking the information that is actually being asked.

Most of our API looks something like this /player, /player:ID, /country etc. Often these endpoints which don’t have any IDs just give you all of the information for that end point and often these endpoint which do have an endpoint, gives you the information about only one of the resource, but again the information is completely full and whether you require those information or not it is being served to you.

So for the IDs, the whole information is dumped and when you don’t have ID, you get giant pile of data. The only advantage that we get when we mention the ID is, we’re asking for one particular resource that we’re looking for, but still a lot of information is dumped. I am not getting just the name, height, gender and the highest score of that player but getting a lot more information like last name, email etc.

Example of Overfetching:

{
"player_details": {
"height": "2.1",
"weight": "78",
"gender":"M"
"age": "28",
"nationality": "USA",
"city": "NYC",
"state": "NY",
"zipcode": "1001",
"highest_score": "98",
"first_name": "Iron",
"last_name": "Man",
"middle_name": ""
"email":"iron.man@firecamp.io"
}
}

Example of Underfetching:

{
"player_name": {
"first_name": "Iron",
"last_name": "Man",
"middle_name": ""
}
}

Now imagine, you’re fetching 100 IDs so you’ll be making 100 API request and 100 response will be served to you. And now you’re extracting 5 information out of that. That is very very costly even for Facebook. They eventually thought that yes, we can cut down our resource consumption if we act a little bit smarter. The solution came in the form of GraphQL.

In GraphQL you can make selective end points like you don’t have to dump end points, you can just pick up selective information from that end point using GraphQL. It can dig a little bit deeper into you API end point and can pick selective information.

Resources consumption in GraphQL v/s REST API

The above issue of Over Fetching and Under Fetching in the REST API leads to either heavy data transfer or multiple calls by the API consumer. In both cases, the resource is heavily consumed by the API server and hence makes the REST API to consume more resource than GraphQL

URL Routes in REST API vs GraphQL Schema

The unpredictable API won’t be useful. When you use an API, you’re usually doing it because it is anyhow a part of the program, and obviously that program needs to know things like what it can call and what it can predict to get as the result, So that it can manage that result. No doubt the most important part of an API is the character of what can be accessed. And this is the exact thing you’ll notice when you read the API documentation, and on the other hand with GraphQL introspection and REST API schema systems like Swagger, we can examine this information programmatically. In the present time REST APIs, the API is usually narrated as a list of endpoints:

GET /books/:id GET /authors/:id GET /books/:id/comments

Now you could definitely say that the “shape” of the API is threadlike- There are things in a list to which you can give access. When you’re retrieving data or saving something, now the most important thing is “which endpoints should you call”?

In GraphQl, as we discussed above, you don’t need to use URIs which are accessible in the API. Instead of that, you can use a GraphQL schema which is following as :

type Query {
book ( id: ID!) : Book
author ( id: ID!) : Author
}
type Mutation {
addComment (input : AddCommentInput) : Comment
}
type Book {. . .}
type Author{. . .}
type Comment {. . .}
input AddCommentInput { . . .}

Now if you notice there are a few interesting bits here when we compared the similar data set to the REST routes. First, GraphQL uses a different initial type – instead of sending a unique HTTP verb to a similar URL to differentiate a read vs. a write. The best thing about in a GraphQL document is that you can actually select which type of the specific operation you’re sending with a keyword:

Query {. . .}
Mutation {. . .}

Now if you notice that the fields on the Query type match up fluently with the REST routes we talked about above. That is because this particular type is the entry point into our data, So as far as I know, it is the most similar concept available in the GraphQL to an endpoint URL.

You can get the initial resource from a GraphQL API that is quite similar to REST. Now let’s discuss how you can do that. First, you need to pass a name and now you need to pass some parameters – but the most important difference is where you can go from there. In GraphQL a complex query that fetches additional data according to relationships can be sent as defined in the schema, but the main problem in REST you have to do that through multiple requests, build similar data into the initial response, or one thing more thing you can do is to include some special parameters in the URL to modify the response.

Route Handlers vs Resolvers

Route handler is basically a code that is somehow looking to a specific incoming URL for a request which is POST and a particular code for handling that precise URL and verb. Few examples that come under this: Serve a particular web page, Handle a request done by a browser for a specific web page.

Now let’s talk about the examples: Handle a specific form post – whenever the user logs into the website in the server login form is submitted. And it is handled in Express, such as app.post("/signin", . . .) by a request handler.

Serve a specific web page – it handles the request done by the browser for a particular web page.

You would generally call something like route handler which is targeted at a particular URL and make sure its main purpose is to send a response back to the client for that URL.

Resolvers are basically the collection of the functions that are used to generate the response for a GraphQL query. In other words, resolvers act as a GraphQL query handler. In resolvers, there is a function and they need to return the type. After you declare some type definitions you give them the things that they can call and the types that they should expect so for E.g a user can call register and they should expect a register response. The idea with resolvers is this is actually the implementation of this so we’re gonna put in here the operation the actual registering of the user for example. And then we’re going to make sure we return the correct data that matches this response

Register (userInfo: UserInfo!): RegisterResponse!

Similarities in GraphQL and REST API

If I had to compare GraphQL and REST api I would be comparing the restaurants nowhere the REST API I would be comparing it as a self-serving restaurant kind of buffet and for the GraphQL, I would be comparing it with a restaurant that is being served by a waiter. Now in a restaurant where you are served as a buffet you just get up from the table and you just go on to each and every table and select the desert from there and maybe you will go and select some vegetable or some bread or something like that but in a restaurant which is served by waiter you just make the smart decision just by sitting on your table.

Pros and Cons of REST/GraphQL

Pros of REST:

  • It is very flexible
  • Mobile-friendliness
  • It is also very appropriate for internet Applications.
  • It is really good for using complex queries.

Cons of REST:

  • Namely the use of a uniform interface.
  • Their nature as a client-server based.
  • Their potential for stateless operations.
  • Its learning curve is not that easy for newbies developers.

Pros of GraphQL:

  • It makes API less cluttered.
  • It is less talkative than REST.
  • It is way faster as compared to REST

Cons of GraphQL

  • In REST JSON schemas come in handy while in GraphQL it’s not.
  • It might encounter a performance issue.
  • It is not that good for simple and small applications.
  • It doesn’t include a specific file uploading feature.

One major disadvantage is that with the help of GraphQL you can make APIs less cluttered. Because many of you have probably seen APIs where you have to Get the user first and then fetch the details.

When to use REST and When to use GraphQL?

Imagine there are a lot of users who are using different platforms one person could be using a web-client using the web browser and the other could be using mobile and the third person could be using any personal IoT device. They are connecting to a telecom service which internally connects to country servers and currency servers now using the clients you can request the telecom service to provide some information and telecom service is now calling two different services country and currency information and retrieving data for the client.

Now, where should we use GraphQL since each client can have different data specifications for eg the web client might request you more data as compared to the one coming from an IoT device so that’s exactly where you can use GraphQL. Because definitely, you don’t want to do over fetching or under fetching in terms of clients. And also you need to provide a good user experience and faster performance in terms of handheld devices like mobile phones and IoT devices. That's where you can use GraphQL so that you can control what amount of data is actually fetched to your device.

However, on the other hand since country service and currency service are already on abounding that context you can leverage REST because there could be other services in your platform which can be consuming of these country service and currency service so you can directly use REST for the country and the currency service while aggregating the data and sending it to the client you can use GraphQL.

And yes you can argue that you can replace the telecom service with an API gateway and obviously an API gateway is going to return the same method which we are using from these clients. And in our case post is going to be used in GraphQL so the same will be passed on to the telecom service. This is the general pattern which we use.

Final Words

When you are working with web APIs in web development you typically have to choose between REST APIs and GraphQL APIs. There are some misconceptions regarding these APIs for example some people think that GraphQL APIs can only be used to react from front-ends which is not true. So basically both GraphQL and REST are really good platform available in the market you just need to know which you should use so if you are building a small and simple application you should probably go with REST and if you to build a complex thing which you want to be really fast then you should probably go with GraphQL.

So in this article, you read about the GraphQL and REST API, limitation of REST API, over fetching and under fetching issues in REST API, URL Routes in both REST API and GraphQL. Every single thing in this world has its pros and cons and we also read about that in this article, We also read when to use GraphQL and when to use REST APIs as well.

CONTENT
What is GraphQL?What is REST API?Limitations of REST APIOver Fetching and Under Fetching issues in REST APIResources consumption in GraphQL v/s REST APIURL Routes in REST API vs GraphQL SchemaRoute Handlers vs ResolversSimilarities in GraphQL and REST APIPros and Cons of REST/GraphQLWhen to use REST and When to use GraphQL?Final Words

Popular Posts

Getting started with GraphQL

GraphQL is a query language designed to build client applications by providing flexible and intuitive syntax for asking the data requirement by clients.

Vyom Srivastava

7 Min Read

Links

DownloadDocChange LogsCookiesTerms & ConditionsPrivacy PolicyContact Us

Apps & Integrations

HTTPGraphQLWebsocketSocketIO

Firecamp Newsletter