Tendo o GraphQL como estrela da publicação, precisamos contextualizar um pouco sobre o tema.
Você também pode ouvir a versão em áudio deste artigo:
GraphQL é uma linguagem baseada em querys com foco em APIs, criada pelo Facebook em 2012, no qual tornou-a open source em 2015, e o processamento destas queries dá-se em tempo de execução. Ou seja, os dados retornados dependem diretamente da query feita. Aí você deve estar se perguntando:“mas isso não é evidente? REST também faz isso, é só mudar o select no server-side”. Sim, é evidente, mas o que torna o GraphQL único é que quem faz a query é o cliente, e não o servidor. Desta forma, sim, haverá queries iguais, mas também queries únicas e sob demanda para cada necessidade.
Por que estamos migrando
Nós possuímos – e continuaremos possuindo até que haja uma migração completa dos produtos que a consomem – uma API REST, como é frequentemente encontrada e disponibilizada por diversas empresas. Contudo chegou um momento no qual a mesma não supria mais as exigências de alguns produtos. É o caso, por exemplo, da extensão da Conviso Platform para o Burp.
Em algumas situações era preciso utilizar mais de um endpoint para conseguir uma determinada informação ou realizar uma operação e, em algumas destas situações, havia-se a necessidade de intercalar entre versões da própria API, tornando rotinas de consulta, manipulação ou até mesmo automação mais trabalhosas e menos performáticas. Também necessitávamos de uma documentação mais completa e que pudesse ser atualizada conforme o próprio desenvolvimento e disponibilização de recursos da mesma, afinal de que adianta termos uma caixa de ferramentas se você não sabe utilizá-la?
Outra demanda que possuíamos, era a necessidade de manipular o conteúdo exibido/retornado ao cliente com mais facilidade, ou seja, uma paginação mais dinâmica, quantidade de itens por página definida pelo usuário, etc. Levando todos os pontos citados anteriormente em consideração, concluiu-se que GraphQL era a solução mais viável para as nossas demandas no momento dado nosso contexto interno. Sendo assim, iniciou-se o processo de mudança/migração para essa nova tecnologia, e daremos mais detalhes sobre este processo no tópico a seguir.
Como implementamos o GraphQL
Considerando as tecnologias disponíveis para implementarmos o GraphQL, buscava-se quais teriam o menor impacto e/ou esforço, pois a nova API não poderia impactar nas nossas operações já existentes, assim como havia a necessidade de entregarmos recursos o quanto antes. Desta forma, concluímos que a melhor opção seria manter-se próximo ao que já possuíamos na Conviso Platform Ou seja, utilizarmos Ruby e suas preciosas gems para realizarmos o processo da forma mais sutil possível.
Utilizando a abordagem de menor esforço/impacto, visamos reutilizar de forma parcial ou integralmente recursos que já possuíamos na Conviso Platform. Como, por exemplo, regras de negócio, autenticação, sessão, entre outros, tornando assim o tempo de desenvolvimento de novos recursos mais curto e, consequentemente, tendo uma curva de aprendizado desta tecnologia menor, visto que é possível criar associações com algo já existente. Vale ressaltar que neste processo não foi possível reaproveitarmos tudo. Houve e sempre haverá refatoração de código, pois o intuito é sempre melhorarmos os processos e as operações.
Para consolidarmos e testarmos as gems, realizamos provas de conceito em alguns cenários. Ou seja, foram implementadas queries na API GraphQL e realizados benchmarks em alguns critérios, como velocidade, usabilidade, etc. Um dos benchmarks que apresentou um resultado surpreendente foi o de velocidade, pois realizamos uma consulta nos projetos que funcionários da Conviso possuem acesso, e tal consulta está disponível a seguir.
query{
listProjects{
id
occurrences{
id
}
}
}
Nesta query pode-se identificar que são consultados todos os id’s dos projetos e, destes projetos, todos os id’s das ocorrências vinculadas – vulnerabilidades e notificações reportadas. Essa query nos retornou mais de 7600 projetos e suas respectivas ocorrências, porém levou uma média de 30 segundos para processar todas essas informações.
Vantagens
Em pouco tempo de uso, já foi possível identificar algumas das vantagens que o GraphQL tem a oferecer e vamos contar um pouco sobre algumas delas a seguir:
Velocidade
É sempre um terreno delicado quando se fala de benchmarks de velocidade, pois há muitos fatores que podem vir a interferir. É o caso, por exemplo, da latência de conexão, processamento do servidor, entre outros. Contudo, como visto anteriormente, mais de 7600 projetos e suas respectivas ocorrências foram retornadas em uma média de 30-40 segundos.
Agilidade no desenvolvimento
Houve redução de forma drástica no desenvolvimento e na curva de aprendizado de novas operações.
Documentação
Como GraphQL é fortemente tipado e a documentação é elaborada no próprio código, durante o desenvolvimento não há mais como deixá-la para ser feita posteriormente. Ou seja, conforme os recursos vão sendo desenvolvidos, os mesmos vão sendo documentados e serão disponibilizados de maneira conjunta. Vale ressaltar que clientes de GraphQL costumam disponibilizar uma documentação interativa durante a sua utilização. Porém também é possível oferecê-la de uma maneira mais popular como a nossa documentação pública.
Conclusão e trabalhos futuros
Levando em consideração todos os aspectos apresentados e melhorias vistas com a utilização do GraphQL, continuaremos a migrar os recursos, bem como nossos produtos e serviços para consumirem e utilizarem a nova API. Haverá também a necessidade de ampliarmos os recursos disponíveis através da mesma, desta forma, todo desenvolvimento passará a ser e utilizar GraphQL.
Conteúdos relevantes:
