sepultura com a inscrição RIP

O surgimento das APIs revolucionou a forma como acessamos dados no universo da computação. A partir de então foi possível ter acesso remoto a qualquer dado, independente de onde ele estivesse armazenado.

Hoje, ninguém precisa ter uma cópia dos dados do Facebook ou do Google Maps para ter os mesmos dados que estes serviços possuem. Basta ter acesso a uma API que entregue os dados na medida em que eles são necessários.

Ao mesmo tempo, o advento do RESTFULL nos libertou do "jardim murado" das tecnologias proprietárias, permitindo que utilizássemos a melhor tecnologia para um determinado fim, o que fez "florescer" a utilização de bancos de dados não relacionais, por exemplo. A solução simples utilizada pelo REST foi utilizar um protocolo verdadeiramente universal - o HTTP - e um modelo de organização lógica que é intuitivo e rápido de entender.

Mas o REST já começou a demonstrar a sua idade, na medida em que é cada vez maior o número de dispositivos e sistemas que precisam consumir e gravar dados através de APIs. Um dos problemas mais comuns é a necessidade de executar múltiplas chamadas a API para ter acesso a todos os dados que são necessários para uma tarefa específica. Leve em consideração o seguinte exemplo:

  • uma chamada a user/:id retorna os dados relativos ao usuário id como nome, email, idade, etc.;
  • uma chamada a user/:id/friends trás a lista com os nomes e ids de todos os amigos conectados ao usuário :id

Se eu por acaso quiser saber a média de idade dos amigos de um determinado usuário, precisarei fazer 1 chamada para buscar a listagem de amigos deste e mais 1 chamada para cada amigo nesta lista. A não ser que seja disponibilizada uma rota para este fim. É aí então que surgem as v1, v2, v3, etc... No mínimo, deveria haver uma forma mais fácil de fazer algo do tipo.

Projetos como o Falcor e GraphQL, lançados como software livre por Netflix e Facebook, respectivamente, tem como objetivo resolver justamente este e outros problemas de acesso remoto a dados através de APIs.

Em ambos os casos trata-se de um serviço que se conecta diretamente a uma ou mais fontes de dados, gerando um grafo e possibilitando que uma determinada requisição, solicite ao servidor apenas os dados dos quais ela necessita.

Dentre outros cenários, projetos como esses parecem muito úteis no ambiente de microsserviços. Imagine o cenário onde há um cliente web e diferentes clientes mobile. Cada um deles precisa de uma versão levemente diferente dos dados para conseguir compôr a interface que será apresentada para o usuário. Como cada cliente solicita ao servidor exatamente aquilo que precisa, fica muito mais fácil manter e evoluir a API mesmo que as necessidades mudem no futuro e sem que seja necessário fazer uso de versionamento.

Texto originalmente publicado na coluna "Post do Kemel" na revista Locaweb #70