GraphQL

GraphQL

1. O que é GraphQL ?

   • Criado pelo Facebook em 2012 mas liberado como open source em 2015
   • Novo padrão de API (assim como REST mas não é REST)

2. Quais problemas o GraphQL resolve ?

   • UnderFetching
     • No caso do REST muitas vezes temos que bater em mais de um endpoint para resgatar todas as informações que o nosso cliente precisa
   • OverFeching
     • Muitas vezes no REST quando batemos em um endpoint para resgatar informações, a API retorna dados desnecessários (que o client não precisa para aquele momento)
   • Entrega para o nosso client apenas os dados que foram requisitados

3. Conceitos básicos

   • Type-System
     • Sistemas de tipos que utilizamos para descrever os dados
   • Queries
     • Sistema de consulta aos dados em um banco de dados (Read)
   • Mutations
     • Sistema de gravação (manipulação) de dados em um banco de dados (Write)
   • Schemas
     • Sistema que define o "Esquema" da nossa API (é como um container onde vamos definir todosos tipos de nossa API)

4. Conceitos avançados

   • Subscriptions
     • Forma de conexão realtime, ele observa algum evento como Mutation ou Query e executa algo caso for definido
   • Directives
     • Servem para modificar campos em nossas Queries

5. Execução

   • Resolvers
     • É um método para implementarmos uma função onde conseguimos "resolver" os dados e retornar os mesmos como response
       • Parametros que recebemos na função de um Resolver
         • Parent
           • Objeto pai do campo em questão
         • Args
           • Argumentos que eu passo para o meu resolver utilizar na função
         • Context
           • Contexto geral passado por nossos middlewares, nele podemos colocar objetos que vamos utilizar em toda a nossa aplicação como Tokens, instancias de bds ou até mesmo informações do usuário
         • Info
           • Este campo tras algumas informações que a query esta executando como por exemplo, os campos que solicitamos, etc
   • Resolvers triviais
     • Encarregado de "resolver" os campos de um Type, é o resolver mais simples e que nao precisamos implementa-lo pois o proprio GraphQL faz isso automaticamente para nos
       • Ele simplesmente retorna a instancia do nosso Parent para o campo especifico por exmplo: `User ... return parent.user`

6. Scalar Types

   • Sao basicamente os tipos primitivo de dados
     • String
       • Uma sequencia de caracteres UTF-8
     • Int
       • Um inteiro de 32 bits (assinado)
     • Float
       • Um ponto flutuante de dupla precisao (assinado)
     • Boolean
       • True ou False
     • ID
       • Representa um identificador unico, geralmente usado para rebuscar um objeto ou como chave de cache

7. Como os campos sao resolvidos ?

   • A forma de como os campos sao resolvidos no GraphQL e em forma de Arvore

8. Tipos de arquitetura com GraphQL

   • Servidor GraphQL com coneccao a um database
   • Servidor GraphQL agindo como middleware, batendo em APIs legado, APIs de terceiros e APIs onde voce esta migrando de REST para GraphQL
   • Servidor GraphQL com coneccao a um database e agindo como middleware para outras APIs REST

9. Seguranca

   • TimeOut
     • Podemos definir um tempo limite para que nossas requisicoes sejam realizadas, se nossas requisicoes nao se resolverem nesse tempo o server ira mandar um error ao inves de mandar um result
       • Pros
         • Simples implementacao e a maioria das aplicacoes utilizam timeout como estrategia de seguranca
       • Cons
         • Os danos ja podem sem infligidos em nossa API mesmo com o tempo limite e as vezes e dificil implementar pois cortar a conecao pode causar comportamentos estranhos em nossa aplicacao
   • Maximum Query Depth
     • Podemos definir um nivel de profundidade que a nossa query vai suportar, caso alguma query ultrapasse esse limite nos podemos enviar um erro como result da requisicao
       • Pros
         • Uma vez que o AST do documento é analisado de forma estática, a consulta nem sequer executa, o que não adiciona carga no seu servidor GraphQL
       • Cons
         • A profundidade sozinha geralmente não é suficiente para cobrir todas as consultas abusivas. Por exemplo, uma consulta solicitando uma quantidade enorme de dados e nós na raiz será muito cara, mas provavelmente não será bloqueada por um analisador de profundidade de consulta
   • Query Complexity
     • Podemos definir uma complexibilidade maxima para nossas queries, e caso alguma query ultrapasse o nivel de complexibilidade maxima que definimos, mandamos um erro em nosso result
       • Pros
         • Abrange mais casos do que uma simples profundidade de consulta e rejeite as consultas antes de executá-las analisando estaticamente a complexidade
       • Cons
         • Difícil de implementar perfeitamente. Se a complexidade é estimada pelos desenvolvedores, como podemos mantê-lo atualizado? Como encontramos os custos em primeiro lugar? As mutações são difíceis de estimar. E se eles tiverem um efeito colateral que é difícil de medir como filmar um trabalho de fundo?
   • Throttling
     • Throttling Based on Server Time
       • Bloqueia as chamadas do client baseado em um tempo de resposta (tempo que o server demora para executar alguma requisicao) e o libera assim que o tempo limite seja liberado novamente, por exemplo: se temos uma requisicao que demora 200 ms para ser resolvida e levando em conta que estimamos o tempo limite de requisicoes que nesse caso seria 1000 ms, o client so podera realizar essa requisicao apenas 5 vezes em 1 segundo, caso ultrapasse essas 5 chamadas nos enviamos um erro no result e bloqueamos o client para ele dar um stop nas chamadas para o server
     • Throttling Based on Query Complexity
       • Aqui e quase a mesma coisa que o baseado em tempo do servidor, so que ao inves de ser baseado em tempo nos nos baseamos em complexibilidade de query, por exemplo: levando em conta uma query que tem complexibilidade de 3, levando em consideracao que estimamos um limite de complexibilidade 9 o client so podera realizar essa requisicao apenas 3 vezes a cada 1 segundo, caso ultrapasse esse limite de 3 chamadas nos podemos enviar um erro no result da requisicao e bloqueamos o client para que ele pare de realizar as chamadas
         • Essa tecnica ja e muito bem utilizada pelo GitHub

10. Escalabilidade

11. Performance

    • Data Loader
      • Aplicando os Data Loaders, nos conseguimos diminuir a quantidade de requisicoes para o nosso database, com isso nos realizamos somente as consultas ao database que sao necessarias para montar nossa response
    • AST
      • Aplicando o AST nos conseguimos diminuir a query que vai para o nosso database deixando assim o tempo de resposta mais rapido, com isso nos mandamos apenas os campos necessarios que pedimos na requisicao

Imagens e arquivos do mapa