33

Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.

Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?

John Topley
  • 113,588
  • 46
  • 195
  • 237
Lazar Lazarov
  • 2,412
  • 4
  • 26
  • 35

1 Answers1

45

This question is primarily opinion-based.

But from my experience: Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.

A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.

Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.

There are cases the one or the other approach would yield better results, but that greatly depends on your situation.

sschrass
  • 7,014
  • 6
  • 43
  • 62
  • 1
    you are right when you say `Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this` Initially every team makes the optimized endpoint(that gets all consolidated data) .But we need more data on client over the time which was not required during initial phase, then instead of making one new optimized endpoint we use the existing ones and make multiple calls. – M Sach Sep 08 '19 at 05:22
  • So with rest we have to do more work here even if we avoid multiple calls. I believe with GraphQL it becomes very easy – M Sach Sep 08 '19 at 05:22
  • The point is if you want to drive client behaviour you have to favor rest, if you don't care what your data is being used for, GraphQL is a viable option. The bad reputation of REST comes from 'so called REST-APIs' to a very large degree, because their resources are merley a representation of database-enitites. Of course optimizing or adding resources (not necessarily endpoints) needs some work, but that´s an easy thing to do technically. – sschrass Sep 08 '19 at 08:48
  • 2
    I agree . On different note , you said `The bad reputation of REST comes from 'so called REST-APIs' to a very large degree, because their resources are merley a representation of database-enitites.` My point is even if they are just representation of database entities, what is wrong in it to call them rest api's ? – M Sach Nov 12 '19 at 15:09
  • They are lacking hypermedia (text and controls (e.g. links)). – sschrass Mar 26 '20 at 17:00
  • Having 1 field from a database in a single trip for example, and more requests for other fields later is the case in GraphQL will make at least double the round trips to the server back and forth VS single request in a REST API with more data. It is according to the use case. But having multi round trips to server in GraphQL costs you much specially if the client is a mobile. And a browser will also invoke 2 or more requests instead of 1. This is why they thought about transactions/pipelines in SQL or Redis to lower round trips to server and HTTP is tougher than 2 SQL statements. – Mostafa A. Hamid Jun 24 '20 at 17:00
  • I can add also to that is beside each GraphQL request will be a round trip from the client to the server and a round trip to the database from the server to database server. In REST it is one round trip to the backend and one round trip from the backend to the database. – Mostafa A. Hamid Jun 24 '20 at 17:03
  • Let us put this in 2 pages you want to view and the 2 pages on the mobile devices can have a single REST endpoint you can hit to get all the data of these 2 pages at once and the request will cost 3 seconds to call the server and display the 2 pages. Using GraphQL, you will send 2 requests and each request will have 3 seconds to the server, you will have 6 seconds to display the data. Regardless of the size of the data. Just the HTTP request Cost even with empty data. 2 request will take double the time of one requests. Even with empty data transferred. – Mostafa A. Hamid Jun 24 '20 at 17:07
  • _"A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists."_. Spring Data Rest considered Anti-Pattern since it provides just that (and a bit more) ?!!!!!!. I do not agree with this answer at all. Wither API resources is representation of database entities or domain entities or whatever is irrelevant to providing each resource with it's common verbs/operation a.k.a crud ! – Anddo Oct 31 '20 at 12:12
  • This is a totally different question you are pointing at and there are lots of resources that worked out the details. Ultimately you will come to the conclusion that REST isn't CRUD. Interestingly it is totally easy and legit to have a REST Api with no database at all. – sschrass Oct 31 '20 at 14:54
  • I don't disagree that REST isn't CRUD but this is one thing. Using REST to expose resources with CRUD operations (irrespective to type of resource being database/domain/dto) and calling it an Anti-Pattern is another. Please refer me to one of the resources worked out details about my question. – Anddo Nov 02 '20 at 17:39