{"id":2761,"date":"2020-10-06T00:05:00","date_gmt":"2020-10-06T03:05:00","guid":{"rendered":"https:\/\/www.magenteiro.com\/blog\/?p=2761"},"modified":"2020-10-02T03:16:11","modified_gmt":"2020-10-02T06:16:11","slug":"graphql-basico","status":"publish","type":"post","link":"https:\/\/www.magenteiro.com\/blog\/magento-2\/graphql-basico\/","title":{"rendered":"GraphQL: Entenda o b\u00e1sico"},"content":{"rendered":"\n

GraphQL (l\u00ea-se graf-quiu-el<\/em>) \u00e9 uma linguagem usada para fazer consultas em APIs. Em outras palavras, trata-se de uma nova forma de se consumir e criar APIs diferente do modo como fomos acostumados.<\/p>\n\n\n\n

GraphQL vs. REST<\/h2>\n\n\n\n

Imagine que voc\u00ea est\u00e1 construindo uma p\u00e1gina de categoria para um e-commerce. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Agora imagine que voc\u00ea n\u00e3o quis usar a tecnologia dispon\u00edvel nativamente na plataforma para personalizar o front end<\/em>. No caso do Magento 2, voc\u00ea usaria KnockoutJS, RequireJS<\/a>, mexeria com arquivos XML’s<\/a>, sobrescreveria temas e m\u00f3dulos<\/a>, entre outras coisas inerentes \u00e0 sua customiza\u00e7\u00e3o de layout.<\/p>\n\n\n\n

Ao inv\u00e9s disso voc\u00ea decidiu usar outra tecnologia e precisar\u00e1 consumir as APIs da plataforma para popular estes dados.<\/p>\n\n\n\n

Voc\u00ea pode fazer isso da forma tradicional, com as APIs REST ou com as APIs GraphQL.<\/p>\n\n\n\n

REST<\/h3>\n\n\n\n

No mundo REST voc\u00ea eventualmente teria que consultar algumas APIs e fazer algumas chamadas para obter os dados necess\u00e1rios para popular a p\u00e1gina acima.<\/p>\n\n\n\n

  • API de Produtos – para buscar os produtos desta categoria<\/li>
  • API de Categorias – para listar outras categorias no menu<\/li>
  • API de Cliente – para ver se o cliente est\u00e1 logado e mudar textos e links de navega\u00e7\u00e3o<\/li>
  • API de Carrinho – para atualizar a quantidade de itens que o cliente tem no carrinho (exibida no canto superior)<\/li><\/ul>\n\n\n\n

    E isso seria apenas o come\u00e7o.<\/p>\n\n\n\n

    Obviamente, muitos destes resultados poderiam ser cacheados em um middleware<\/em>, evitando que chamadas repetidas fossem feitas novamente.<\/p>\n\n\n\n

    Al\u00e9m de ter que fazer v\u00e1rias chamadas<\/strong> para obter os dados desta p\u00e1gina, eventualmente estas APIs tamb\u00e9m trariam muitos dados que voc\u00ea n\u00e3o precisa<\/strong>. Por exemplo, a API de produtos eventualmente lhe trar\u00e1 diferentes tamanhos de imagem, e outros atributos que n\u00e3o precisamos nesta p\u00e1gina.<\/p>\n\n\n\n

    GraphQL<\/h3>\n\n\n\n

    Em uma API GraphQL ao inv\u00e9s de fazer diversas chamadas, voc\u00ea faria apenas uma.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Voc\u00ea solicita as informa\u00e7\u00f5es que precisa, e somente<\/strong> aquelas informa\u00e7\u00f5es s\u00e3o devolvidas.<\/p>\n\n\n\n

    A organiza\u00e7\u00e3o de uma API GraphQL \u00e9 feita por tipos e campos e n\u00e3o por endpoints. Desta forma, APIs GraphQL geralmente possuem apenas uma URL.<\/p>\n\n\n\n

    Al\u00e9m disso, ao construir as chamadas no formato GraphQL usando um programa apropriado, geralmente temos recursos de autocompletar e acesso \u00e0 boa parte da documenta\u00e7\u00e3o exibida automaticamente.<\/p>\n\n\n\n