Mind map
GraphQL
Map content
GraphQL
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)
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
- UnderFetching
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)
- Type-System
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
- Subscriptions
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
- Parent
- Parametros que recebemos na função de um Resolver
- É um método para implementarmos uma função onde conseguimos "resolver" os dados e retornar os mesmos como response
- 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`
- 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
- Resolvers
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
- String
- Sao basicamente os tipos primitivo de dados
Como os campos sao resolvidos ?
- A forma de como os campos sao resolvidos no GraphQL e em forma de Arvore
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
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
- Pros
- 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
- 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
- Pros
- 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
- 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?
- Pros
- 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
- 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
- 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
- Throttling Based on Server Time
- TimeOut
Escalabilidade
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
- Data Loader