11949183
Description
Mind Map by Julio Cesar Caetanu, updated more than 1 year ago
|
Created by Julio Cesar Caetanu
about 6 years ago
|
|
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)
- Criado pelo Facebook em 2012
mas liberado como open
source em 2015
- 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
- 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)
- 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
- Sistemas de tipos que
utilizamos para descrever os
dados
- Queries
- Sistema de consulta aos
dados em um banco de
dados (Read)
- 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)
- 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)
- 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
- 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
- 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
- Objeto pai do campo em questão
- Args
- Argumentos que eu passo para o
meu resolver utilizar na função
- 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
- 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
- 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`
- 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
- Uma sequencia de caracteres UTF-8
- Int
- Um inteiro de 32 bits (assinado)
- Um inteiro de 32 bits (assinado)
- Float
- Um ponto flutuante de dupla precisao (assinado)
- Um ponto flutuante de dupla precisao (assinado)
- Boolean
- True ou False
- True ou False
- ID
- Representa um identificador unico,
geralmente usado para rebuscar um
objeto ou como chave de cache
- 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
- 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
- Servidor GraphQL com
coneccao a um database
- 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
- 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
- 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
- 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
- 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
- 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?
- 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
- 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
- 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
- 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
- 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
Media attachments
Want to create your own Mind Maps for free with GoConqr? Learn more.