What is the difference between GraphQL and REST?

GraphQL is a search language, so REST also does it.

The difference is that with GraphQL you search exactly what you want (a front-end knows exactly how this works).

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

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

With REST you get all this data, with GraphQL you only get what is necessary for you. This reduces the upload of data sent from the server to the browser.

Insummary,IbelievethisistheadvantageofGraphQL.

SeveralcompaniesaremigratingfromRESTtoGraphQL,takealookatthis list .

If you want to get started, this tutorial is great.

It's also worth seeing post of the New York Times talking about the migration they did.

GraphQL is designed to address, for example, the following problems with REST:

(1) the URL gets complicated with complex relationships and lots of nesting

(2) Overfetching, when you get more data than you need

(3) The problem of making many HTTP requests for various resource types (or if you have to make many requests for the same resource one by one)

In REST, it has a URL with an HTTP verb for each CRUD operation. For example,

• to get all the products of a certain backend: GET /produtos ;
• to get the record for a product: GET /produtos/123456 , where 123456 is the product id.
• and so on

In GraphQL, you only have a single 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 request to get data from, for example, a certain product, the JSON record usually comes with everything it has available on that product.

Sometimes your frontend only needs one or two properties, but the json object comes with a 30+. This becomes a problem, especially if you want to serve mobile application users who do not have a very good connection. This was one of the reasons that the Facebook friends created GraphQL.

With GraphQL, you can ask the backend exactly what you need. For example, in the case of the product, if we just need the name of the product, just do a query to GraphQL like this:

query {
  produto(id: "123456") {
    nome
  }
}

The example above is very simple. It saves the bandwidth as it only returns a property in json pro user format.

Another more complex example is the following. In my work I have come across a lot of situations where an HTTP request to an API does not give me all the necessary information for the frontend. Therefore, I always have to make several other requests (including several other APIs) just to get 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 the 123 product, but maybe it would not include all information about the company. I say this if I use an MVC backend that automatically routes and REST actions. Sometimes doing GET /companhias/4321 gives you access to 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 tricky and harder to understand quickly. And you have to make several customizations in the backend to be able to get all the data you want. Or you would have to make multiple HTTP requests and do data processing in the frontend.

With GraphQL, although you have to configure everything in the backend, the frontend only does 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, in addition to product-specific information 123, in addition to all templates including% with%,% with%,% with%, and% with%. And all this would come from a single HTTP request, from the single endpoint id . It is important to note that the information does not need to come from the same API. You can have multiple APIs in multiple places and use GraphQL to combine everything in one answer.

To conclude, I would recommend using GraphQL if you have constant issues like the ones mentioned earlier.

To complement the above answers, I'll cite a project I worked on recently and implemented graphql.

I was working on a project that consumed a CMS REST API, so I paid the categories, subcategories, products and offers via this API and sent the front-end consume, the problem arose when CMS registrations grew, and the final json that was being sent to the front end was with a size close to 4mb, which 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 give a lot of work.

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

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

So this is the great benefit of GraphQL, allowing the front end to consume only what is needed, and does not necessarily have to be a substitute for REST, because in some cases as legacy systems you can not simply stop using the REST API , so what you can do is put the two together where it makes sense and reap the same benefits.