What is the difference between Graphql and REST?

Question

People have commented a lot about the use of Graphql and with that, some comments that will replace this rise that we have of REST API’s.

• What is the difference between the two (Graphql and REST)?
• And, in what scenario is interesting I opt for Graphql and/or REST?

Answer 1

Graphql is a search language, until then REST also does.

The difference is that with Graphql you seek exactly what you want (a front-end know exactly how it works).

For example, I made an API in Graphql involving the API of my Instagram.

If you click on the link, you will notice that a huge JSON appears.

With REST you take all this data, with Graphql you take only what is necessary for you. This reduces the load of data sent from the server to the browser.

In short, I believe that this is the advantage of Graphql.

Several companies are migrating from REST to Graphql, take a look at this list.

In case you want to start, this tutorial is excellent.

It’s worth seeing this one too post of New York Times speaking of the migration they have made.

Answer 2

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.

Answer 3

To complement the above answers I will cite a project I recently worked and implemented graphql.

I was working on a project that consumed a CMS REST API, so I paid for the categories, subcategories, products and offers via this API and ordered pro front-end consume, the problem arose when CMS registrations grew, and the final json that was being sent to the front end was about 4mb in size, q is a lot, and to solve this I had two options:

1 - Filtering the data on the server, which would require a lot of code and specific treatments, would be a lot of work.

2 - Create a graphql server and consume this REST API via graphql.

I chose option 2 and this made the response json size drop from almost 4mb to 50kb in some cases, because I started to request only the necessary for the server, and this along with some caching techniques solved my problem.

So this is the great benefit of Graphql, allowing the front end to consume only the necessary, and not necessarily need to be a replacement for REST, because in some cases as legacy systems you cannot simply stop using the REST API, then what you can do is unite the two where it makes sense and reap the same benefits.