⚗️
Consumindo APIs com Elixir
  • Introdução
  • Sobre o autor
  • O valor desse livro
  • Introdução
    • Por que elixir?
    • Como ler este livro
    • Sobre o conteúdo do livro
  • Configurando ambiente
    • Instalando o Elixir
    • Criando um projeto
  • Construindo um cliente usando Tesla
    • Iniciando
    • Tesla
      • O que é o Tesla
      • Instalando Tesla
    • Criando o Client
    • Estruturando resposta
    • Estratégia de teste para requisições
    • Instalando Bypass
    • Mockando requisições do cliente com Bypass
    • Tratando dados da resposta
  • Problemas de API externa
    • Erro genérico
    • O que é o rate limit
    • Rate Limite de curta duração
      • Reexecutando uma requisição
    • Rate Limit de longa duração
      • Agendando uma nova tentativa de requisição
      • Configurações necessárias
      • Adicionando Ecto ao projeto
      • O que é o Oban
      • Instalando Oban
      • Criando uma requisição assíncrona
      • Configurando quantidade de tentativas no Oban
  • Compondo integrações
    • Level up
    • Marvel API
      • Criando uma conta
      • Lendo o endpoint de Comics
      • Criando o cliente da Marvel
        • Melhorando a segurança
      • Lidando com a resposta
    • Aproveitando ao máximo o Rate Limit
  • Em breve
    • WIP - Supervisor
    • WIP - OAuth
    • WIP - Cacheando requisições
Fornecido por GitBook
Nesta página

Isto foi útil?

  1. Compondo integrações

Aproveitando ao máximo o Rate Limit

AnteriorLidando com a respostaPróximoWIP - Supervisor

Atualizado há 1 ano

Isto foi útil?

Mesmo tendo mecanismos para lidar com o Rate Limit ultrapassado, precisamos também aproveitar ao máximo as requisições e tentar não entrar na penalidade, ou entrar o mínimo possível, para entregar uma experiência melhor ao usuário.

Uma das formas de fazer isso é utilizando ETag, um mecanismo de versionamento de recurso.

Hoje nossa aplicação funciona assim

Vamos recapitular.

Nossa aplicação realiza uma requisição para o serviço externo requisitando o recurso /coffee/hot. O serviço externo processa, pega os dados de algum sistema de armazenamento e retorna o recurço. Na resposta recebemos um cabeçalho com x-ratelimit-remaining . Toda vez que fizermos esse processo, esse cabeçalho diminuirá 1, até chegar a zero e então receberemos o erro de status 429 acusando que fizemos requisições demais em um curto período de tempo.

Imagine agora que o serviço externo versiona os dados do recurso. Isso quer dizer, toda vez que o dado muda, ou um cafezinho é adicionado, ele gera um código informando que essa é a versão atual e responde esse código pelo cabeçalho para nós, quem está requisitando o recurso. Vamos dizer que o código seja 123456. Chegou a hora que precisamos fazer novamente um requisição a esse recurso, pois alguém chamou a função de integração. Tendo o código da versão do recurso podemos mandar por cabeçalho. Feito isso, do o serviço analisara esse código, verificando se é a versão atual. Se não foi, ele irá retornar os dados do recurso, junto com o codigo mais recente. Caso o código que nós enviamos seja igual ao da versão atual, ele vai nos responder com status 304 Not Modified e o corpo da requisição virá vazia. Isso quer dizer que o dado que temos é o atualizado.

Nesse cenário o x-ratelimit-remaining não é decrementado. Isso acontece devido a não ter processado o dado no lado do serviço. Essa regra faz com que não consumemos muito recurso, com isso não nos penalizando.

Porém, não recebemos o dado na requisição. Precisamos ter ele em nossa aplicação em alguma forma de armazenamento. No nossa caso, podemos adicionar no banco de dados.