3

I want to make sure I understand how GraphQL works. Here's my understanding of one way of how GraphQL is superior to RESTful APIs. Say you have a user model:

{
  user: {
    firstName: "John",
    lasName: "Smith",
    username: "jsmith",
    email: "jsmith@company.com",
    gender: "M",
    password: "password"
  }
}

Then, you make an API call to get this user's info for your app's profile page. Let's assume you only want the user's firstName (maybe to display a welcome message).

axios.get(get_user_info_url).then(res => {
  const firstName = res.data.user.firstName
})

So, what's happening here is that the res from the server includes all of that user's info, which includes data that we don't care about (such as his username and email). That means that the server is downloading all of this user's data, and sending it back to the client. But, the client only cares about the firstName, and basically disregards everything else. So, if the user model has dozens (or hundreds) of attributes on it, we would be overfetching because we're downloading data that we simply don't need.

In this example, to get his first name, we have to set res.data.user.firstName. With GraphQL, however, the server sends back only the user's firstName, and not the rest of his info. So, with GraphQL, we are not downloading the entire user model from the server (overfetching). Rather, we are only downloading the data that we need (like his firstName). This would be beneficial if the user had dozens of attributes because we would only fetch/download the data that we actually need.

Is this understanding of GraphQL correct?

E_net4
  • 27,810
  • 13
  • 101
  • 139
Farid
  • 1,557
  • 2
  • 21
  • 35
  • 1
    You are comparing apples with pears. GraphQL is like SQL query language for the Web while REST is a technique to decouple clients from servers (if done correctly). The so called RESTful services, so many vendors advertise, hardly deserve the term REST as they are more like RPC via HTTP. By specifying what fields to return, GraphQL applications further have to have some knowledge about the available data beforehand retrieving it, which might couple the client to the server already and thus violate the REST principles. Btw, how does the title link to the actual question? – Roman Vottner Feb 18 '18 at 11:35
  • Valid point. To clarify, I'm referring to only the web development space where HTTP requests are made by a client to a server (mobile and web). Assuming you know what data you want from the server, it sounds like GraphQL is the more efficient way of getting that data. That's what I gathered from https://www.howtographql.com. GraphQL is supposed to serve as a superior alternative to REST – Farid Feb 18 '18 at 11:41
  • If you read through [Fieldings blog post](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven) you might learn that preassuming that a certain resource has a certain type is actually against REST principles (= [typed resources](http://soabits.blogspot.co.at/2012/04/restful-resources-are-not-typed.html)). – Roman Vottner Feb 18 '18 at 11:59
  • 4
    The benefit you are pointing out is not so huge since usually all responses are compressed. What is more beneficial from a client perspective is that you can request all you need in one single request. To gather all the data from a RESTful web service might need multiple requests especially if you a have a lot of sub resources. On the other hand with GraphQL the caching possibilites will suffer. – Kingson Feb 18 '18 at 12:52
  • Can you provide an example? – Farid Feb 19 '18 at 02:07
  • @Kingson when you say ` usually all responses are compressed` does http do it be default or in application we have to do it explicitly ? If explicit, do we have to tell browser/client to decompress it or is it done by default ? – user3198603 Sep 08 '19 at 03:54
  • @user3198603 It's a combination of client and server. The client needs to send an Accept-Encoding header to tell the server, that it can understand compressed responses (for example: Accept-Encoding: gzip). Then the server can compress the response, which is done by the webserver (some configuration is needed) or the web application itself. Mostly it's easier and more common that the webserver handles the compression. – Kingson Sep 22 '19 at 06:55
  • Thanks Kingson. You said To gather all the data from a RESTful web service might need multiple requests especially if you a have a lot of sub resources. On the other hand with GraphQL the caching possibilites will suffer.` My point is even in restful services you can create a contract which can provide all required data in one request instead of multiple. Isn't it ? Second point you said caching will suffer in GraphQL . My point : GraphQL is also http request with graphql query in it. So why it can't be cached ? Is it because of POST request in graphql ? – user3198603 Nov 12 '19 at 15:03
  • Doing many requests is also not nearly as bad was it was before HTTP/2. It's actually kinda nice to request a whole bunch of stuff and be able to render things as they come in. The slowest request is not going to slow *everything* down, unlike GraphQL. – Evert Jul 24 '20 at 00:05
  • Does this answer your question? [Are there any disadvantages to GraphQL?](https://stackoverflow.com/questions/40689858/are-there-any-disadvantages-to-graphql) – Michael Freidgeim Jul 25 '20 at 06:18

1 Answers1

0

I believe GraphQL is more applicable when you know you will require much more data than only one field. It helps to avoid "overfetching" of fields and properties. And it gives you the opportunity to fetch it by making less requests to the server, comparing to REST, reducing latency. Both communication interfaces have their drawbacks, but as any tool they are as good as the one holding them :)

Dmitry Vaskovskyi
  • 11
  • 1