Graphql was created to address, for example, the following problems with REST:
(1) URL gets complicated with complex and very nesting relationships
(2) the problem of "overfetching," when you get more data than you need
(3) the problem of making many HTTP requests for various types of resources (or if you have to make many requests for the same feature, one by one)
In REST, you have a URL with an HTTP verb for each CRUD operation. For example,
- to get all products from a certain backend:
GET /produtos
;
- to obtain the recovery of a product:
GET /produtos/123456
, where 123456 is the product id.
- and so on
In Graphql, there is only one endpoint, usually POST /graphql
. All operations are performed through this path. To get data, you make a query. To modify the data, you make a Mutation. For subscriptions, you make a Subscription.
In REST, when you order to get data from, for example, a certain product, the JSON record usually comes with everything you have available on that product.
Sometimes your frontend only needs one or two properties, but the json object comes with about 30+. This becomes a problem, especially if you want to serve mobile app users who don’t have a very good connection. This was one of the reasons that the Facebook people created Graphql.
With Graphql, you can ask the backend for exactly what you need. For example, in the case of the product, if we only need the product name, just ask Graphql a query like this:
query {
produto(id: "123456") {
nome
}
}
The above example is quite simple. It saves Bandwidth as it only returns a json file for the user.
Another more complex example is the following. In my work I have come across a lot of situations where an HTTP request for an API does not give me all the necessary information for the frontend. Therefore, I always have to place several other orders (including several other Apis) just in order to obtain and inject this information into the initial object.
If a Companhia
has several Produtos
; and each product has several Modelos
, making GET /companhias/4321/produtos/123
in REST would give me information about product 123, but perhaps it would not include all information about the company. I say this if I use an MVC backend that generates REST routes and actions automatically. Sometimes doing GET /companhias/4321
gives you access to the products, but each product does not include information about the models (it would only include the modeloId
of each).
You already see that the above business gets complicated and harder to understand quickly. And you have to do several customizations in the backend to be able to get all the desired data. Or you would have to make multiple HTTP requests and do data processing on the frontend.
With Graphql, although you have to configure everything in the backend, from the frontend you only do the following:
query {
companhia(id: "4321") {
nome
dataDeFundacao
produto(id: "123") {
id
nome
modelos {
id
nome
dataDeLancamento
preco
}
}
}
}
With the above query, you would get specific information about the company 4321, plus the specific information of the product 123, plus all models including id
, nome
, dataDeLancamento
, and preco
. And all this would come from a single HTTP request, from the single endpoint /graphql
. It is important to note that the information does not need to come from the same API. You can have multiple Apis in multiple locations and use Graphql to combine everything in one answer.
To conclude, I would recommend using Graphql if you have constant problems like the ones mentioned above.
Clear and punctual answer. Thank you very much Alessander. Briefly you explained the difference between the two approaches and exemplified with links. I will follow that tutorial you recommended. Thank you.
– Gustavo Bitencourt
I’m glad I was clear. I followed this tutorial and learned a lot ;)
– Alessander França
Adding a post I recently found: https://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b
– Gustavo Bitencourt