Graphql

Introdução

Graphql é uma tecnologia que gerou considerável hype ao propor resolver problemas de centralização de dados, dar ao cliente o poder de selecionar exatamente os dados necessários e fornecer um schema com documentação dos tipos entregues.

Nota pessoal: ao conhecer GraphQL em 2017, o entusiasmo foi imediato. Até hoje, porém, ainda não foi possível colocar em produção um sistema com uso amplo da tecnologia — a busca continua.

O que é o graphql?

Graphql é uma query language que permite que o consumidor dos dados possam fazer queries com os dados que desejam receber. O servidor cria schemas que definem as queries feitas. Cada schema fornece meios para que você possa acessar dados dos objetos entregues pelo servidor.

Observe o seguinte exemplo de schema:

query {
  hero {
    name
    appearsIn
  }
}

Um exemplo direto do site do graphql, com a pequena mudança da adição do query. Essa query acima é realmente uma query, semelhante ao GET do REST, uma opção para pegar recursos dada as informações dos objetos especificados. Nesse exemplo, temos o objeto hero com os atributos namee appearsIn. Porém, o que são essas propriedades do objeto? Como podemos definir ou investigar qual o tipo a ser retornado?

enum Episode {
  NEWHOPE
  EMPIRE
  JEDI
}

type Character {
  name: String!
  appearsIn: [Episode!]!
}

Com esses tipos definidos, fica mais fácil compreender a query anterior. A seguir, uma análise de cada elemento:

• enum Episode: Esse é um tipo especial que define os possíveis valores para um determinado campo. Você já deve ter ouvido falar de enum em Typescript
• type Character: Definição do tipo do nosso objeto, neste caso, iremos chamar de Character
• name: String: definição da property name do tipo String, pertencente ao grupo de scalar types ou em tradução literal, tipos escalares. Que são os tipos primários para a construção de outros tipos
• name: String!: Ainda sobre name, temos um !. Em GraphQL, o ! significa NonNullable — o campo não pode ser nulo.
• appearsIn: [Episode!]!: A notação [] significa um array/lista de types Episode. O ! aparecendo duas vezes remete a um array não nulo e um Episode não nulo.

Scalar Types

Como citado acima, os scalar types podem ser classificados como "primitivos" para que você possa escrever os outros tipos. Ao total, são 4 scalar types:

• Int: Números inteiros de 32 bits
• Float: números com ponto flutuante de dupla precisão. O number do Javascript. Definição IEEE_754
• String: Sequência de caracteres na codificação UTF-8
• Boolean: true ou false.

Você também pode estender a possibilidade de scalar types com a keyword scalar. Mas isso é um assunto pra um post específico de implementação do graphql.

Matador do REST

A resposta curta é: não.

GraphQL e REST não deveriam ser considerados adversários. GraphQL é uma tecnologia relevante, que traz ganhos concretos para o desenvolvimento, mas também traz problemas significativos — em alguns cenários, possivelmente mais problemas do que benefícios. Eis alguns pontos de vistas a se considerar:

• Mais uma camada de abstração: É isso, o graphql acrescenta mais uma camada entre os seus dados e a lógica da sua aplicação. Isso pode não ser muito levado em conta por que utilizamos frameworks que abstraem isso, mas não se esqueça, a abstração está no framework.
• Qualidade da implementação: Ainda sobre acrescentar uma camada, temos o problema de implementação do graphql na linguagem que você utiliza. É preciso aplicar um parser na string que você recebe como query, transformar a string em um schema parseavel pelo algoritmo para que esse algoritmo transforme tudo isso em objetos da sua linguagem alvo.
• Consistência dos dados: O princípio do graphql é criar uma linguagem entre as APIs, de forma que você consiga agregar e centralizar buscas de informações para seus clientes consumirem de maneira mais fácil. Mas e se uma das APIs atualizarem e você não atualizar o seu schema ou a sua forma de pegar esses dados? Vai dar problema né?!
• Autorização e autorização: Apesar de estar no server, o graphql apenas agrega dados de outros lugares e os formata no schema. Mas e se o cliente tentar acessar um recurso que não deveria? Quem vai dizer que não deveria? O graphql ou a API que será consumida? E o retorno de erros para esse cliente? Essas perguntas são um pouco nebulosas e podem causar dúvidas na implementação
• Retrocompatibilidade: Esse é um problema quase que universal, mas em REST conseguimos resolver com o versionamento da API, mas no graphql pode ser um pouco trabalhoso versionar schemas. Apesar de existir @deprecated, ainda pode ser um problema caso você corte alguns pontos do seu schema

Conclusão

Graphql é sem dúvidas uma grande tecnologia que podemos utilizar no nosso dia a dia. Não import a linguagem, você vai ter uma implementação em graphql. Só olhar essa lista. Como disse anteriormente, não faz sentido compararmos Rest e Graphql pois ambos se propõe a resolver o problema da entrega de dados com approaches diferentes, trazendo seus próprios benefícios e problemas.

Vale a pena estudar esta tecnologia, realizar provas de conceito e avaliar se faz sentido adotá-la na arquitetura. Obrigado pelo seu tempo, tamo junto e até a próxima