GraphQL

GraphQL

O que é GraphQL ?
1. Criado pelo Facebook em 2012 mas liberado como open source em 2015
2. Novo padrão de API (assim como REST mas não é REST)
Quais problemas o GraphQL resolve ?
1. UnderFetching
  1. 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
2. OverFeching
  1. 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)
3. Entrega para o nosso client apenas os dados que foram requisitados
Conceitos básicos
1. Type-System
  1. Sistemas de tipos que utilizamos para descrever os dados
2. Queries
  1. Sistema de consulta aos dados em um banco de dados (Read)
3. Mutations
  1. Sistema de gravação (manipulação) de dados em um banco de dados (Write)
4. Schemas
  1. Sistema que define o "Esquema" da nossa API (é como um container onde vamos definir todosos tipos de nossa API)
Conceitos avançados
1. Subscriptions
  1. Forma de conexão realtime, ele observa algum evento como Mutation ou Query e executa algo caso for definido
2. Directives
  1. Servem para modificar campos em nossas Queries
Execução
1. Resolvers
  1. É um método para implementarmos uma função onde conseguimos "resolver" os dados e retornar os mesmos como response
    1. Parametros que recebemos na função de um Resolver
      1. Parent
        Objeto pai do campo em questão
      2. Args
        Argumentos que eu passo para o meu resolver utilizar na função
      3. 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
      4. Info
        Este campo tras algumas informações que a query esta executando como por exemplo, os campos que solicitamos, etc
2. Resolvers triviais
  1. 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
    1. Ele simplesmente retorna a instancia do nosso Parent para o campo especifico por exmplo: `User ... return parent.user`
Scalar Types
1. Sao basicamente os tipos primitivo de dados
  1. String
    1. Uma sequencia de caracteres UTF-8
  2. Int
    1. Um inteiro de 32 bits (assinado)
  3. Float
    1. Um ponto flutuante de dupla precisao (assinado)
  4. Boolean
    1. True ou False
  5. ID
    1. Representa um identificador unico, geralmente usado para rebuscar um objeto ou como chave de cache
Como os campos sao resolvidos ?
1. A forma de como os campos sao resolvidos no GraphQL e em forma de Arvore
Tipos de arquitetura com GraphQL
1. Servidor GraphQL com coneccao a um database
2. Servidor GraphQL agindo como middleware, batendo em APIs legado, APIs de terceiros e APIs onde voce esta migrando de REST para GraphQL
3. Servidor GraphQL com coneccao a um database e agindo como middleware para outras APIs REST
Seguranca
1. TimeOut
  1. 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
    1. Pros
      1. Simples implementacao e a maioria das aplicacoes utilizam timeout como estrategia de seguranca
    2. Cons
      1. 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
2. Maximum Query Depth
  1. 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
    1. Pros
      1. 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
    2. Cons
      1. 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
3. Query Complexity
  1. 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
    1. Pros
      1. Abrange mais casos do que uma simples profundidade de consulta e rejeite as consultas antes de executá-las analisando estaticamente a complexidade
    2. Cons
      1. 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?
4. Throttling
  1. Throttling Based on Server Time
    1. 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
  2. Throttling Based on Query Complexity
    1. 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
      1. Essa tecnica ja e muito bem utilizada pelo GitHub
Escalabilidade
Performance
1. Data Loader
  1. 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
2. AST
  1. 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

Medienanhänge

1*Iv C Dlfi3v Qfgy Ko1e Fv4j A (image/png)

Nächster

Beschreibung

Zusammenfassung der Ressource

Medienanhänge

ähnlicher Inhalt

	Erstellt von Julio Cesar Caetanu vor fast 7 Jahre