GraphQL a bala que não é de prata, mas ajuda bastante :)

Ouvir falar de GraphQL é meio comum na atualidade né?A ideia do texto não é falar do que é e como funciona. É abordar como implementamos no Grupo ZAP, obviamente irei abordar alguns recursos que nos fizeram adotar a tecnologia, mas não é um tutorial. Dito isso vamos lá :)?

O cenário era alguns meses pós fusão ZAP e VivaReal, eu estava no squad responsável pelos sistemas onde o anunciante gerenciava seu inventário. Tínhamos o desafio de unificar a plataforma de maneira que fosse resiliente e performática, visto que todo o nosso ecossistema é baseado em microservices.

É aquele momento que todo desenvolvedor gosta ou teme: escolher as tecnologias que vão moldar um sistema. Gosta pois tem a oportunidade de escolher aquilo que entende que irá atender ao problema a ser resolvido. Teme pois uma decisão não sábia pode te importunar por anos a fora.

GraphQL vs REST?

Todo o time já tinha expertise em montar uma API REST, entretanto tínhamos o problema que o front end web e os apps que iriam consumir a API fariam muitas requisições simultâneas para construir uma interface (o tal do underfetching). Além disso os clients (App e web) não necessariamente precisariam de todos os campos no mesmo momento (over-fetching).

Durante as discussões do squad em como desenhar a API para atender esses problemas, o Alan Mesquita de Sousa (engenheiro de software de outro squad) havia montado uma POC utilizando GraphQL há um tempo e decidimos testar.

Há uma quebra de paradigma ao considerar uma API GraphQL, como fala Lee Byron: “Think in graphs, not endpoints.”. O ponto chave que aprendemos ao validar a POC e iniciar o estudo em GraphQL é que uma coisa não invalida a outra. Por mais calorosa que possa ser uma discussão sobre tudo em REST ou tudo em GraphQL, nunca se esqueça do real problema que você quer resolver.

O teste em cima da POC atendia os problemas que estávamos tentando resolver de maneira simples e eficaz. Precisávamos agora sair da POC e construir o projeto.

Da POC para o projeto

Foto de Bartek Wojtas no Pexels

A documentação oficial do GraphQL é rica e bem completa de exemplos. Usamos como base para definir a arquitetura da aplicação. Isso nos deu agilidade no desenvolvimento, pois a curva de aprendizado nossa foi bem baixa dada a quantidade de exemplos e definições completas do que é cada recurso.

Primeiros passos

Photo by Alexander Dummer on Unsplash

Óbvio que de início não foi fácil entender que tudo era um POST e o client que define o que quer. Mas com a riqueza de detalhes da documentação, a margem para dúvidas e incertezas era mínima.

Decidimos usar express-graphql para essa API pela simplicidade de implementar e integração com o framework Express.

Lidando com autorização

Photo by Ali Yahya on Unsplash

A documentação deixa bem claro que a autorização NÃO deve ficar sob responsabilidade do GraphQL. Implementamos um modelo em que o schema apenas acionava um resolver, e o resolver possuía uma abstração que validava a autorização. Dessa forma a camada do schema só tinha a responsabilidade de acionar o resolver da ação.

Era só subir um arquivo eles disseram

Foto de rawpixel.com no Pexels

Com o andar do projeto, esbarramos em como fazer um upload de arquivo. Por padrão esse tipo não vem no express-graphql e outras implementações do GraphQL já suportavam nativamente(apollo-server). Decidimos usar a biblioteca multer em conjunto com o express-graphqle implementamos o upload para atender a necessidade.

E o underfetching?

Foto de Oleg Magni no Pexels

Não existe magia para o underfetching , logo modelamos os tipos para que as entidades no grafo usassem somente as apis que tangiam aquele escopo. Isso gera uma dor de cabeça inicial, pois você tem que separar as chamadas e garantir que os endpoints que a GraphQL API irá consumir entreguem menos informações e não gerem uma lentidão por má utilização. Contudo isso também gerou um movimento de otimização das APIs internas, pois conseguimos identificar gargalos e oportunidades de melhoria. Exemplo disso foi nossa API de integração de feeds que não havia nenhuma forma de identificar se o cliente integrava conosco de maneira simples. Na implementação anterior ao GraphQL, efetuavamos uma chamada para verificar se já houve alguma execução do cliente.

Garantindo retrocompatibilidade

Foto de Pixabay no Pexels

Versionamento de API é algo que o REST tem, e no GraphQL a abordagem é um pouco diferente. Marcar um campo com deprecationReasonpode parecer estranho na primeira implementação. MAS ao perceber por exemplo que os clients ao pedirem o schema já não mais enxergam o campo e garantir retrocompatibilidade com clients antigos nos deixou de olhinhos brilhando.

Problemas com o monitoramento

Photo by Luke Chesser on Unsplash

O nosso APM na época não interpretava as requisições em GraphQL corretamente, aparecia somente um POST / em toda chamada, nos impedindo de entender os tempos de cada Query/Mutation . Tivemos que implementar um middleware para customizar a transação e não perder essa informação importante.

E a resiliência?

Foto de John Keller no Pexels

Quanto a resiliência, não entra na conta do GraphQL, mas precisávamos atender. Usamos como base a implementação do hystrixjs em um projeto do squad que cuida dos portais ZapImoveis e VivaReal(com grande ajuda do Marcio Rodrigues e Caio Silva). Dessa forma se uma API deixar de responder por um tempo, o circuito abre e garantimos os caminhos críticos.

E o que aprendemos

Atualmente a nossa API em GraphQL atende ao portal do anunciante Grupo ZAP também conhecido como Canal Pro. Dentro do Grupo ZAP temos ainda internamente mais uma API em GraphQL que o squad onde meu amigo Jota Feldmann trabalha. Isso significa um movimento para migramos nossas APIs para GraphQL? Claro que não, não existe bala de prata em tecnologia.

Foto de rawpixel.com no Pexels

No Grupo ZAP não nos limitamos à tecnologia, aprendemos e usamos o que é ideal para resolver a necessidade ou problema. Isso nos permite evoluir e criar uma stack resiliente e escalável.

Quer trabalhar conosco? Temos vagas!

Agradecimentos a André Maldonado, Marcio Rodrigues e Jota Feldmann

Tech@Grupo ZAP

Como fazemos tecnologia nos maiores portais de imóveis do Brasil

Francisco Pereira (Chico)

Written by

Pythonista, apaixonado por tecnologia, filosofia e astronomia.

Tech@Grupo ZAP

Como fazemos tecnologia nos maiores portais de imóveis do Brasil

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade