REST vs GraphQL | Quando usar qual?

gente o tema de hoje ele é bem difícil ele é bastante polêmico ele é bastante controverso então eu vou ser bem Raso e bem vago na minha análise a ideia aqui não é bater o martelo e dizer que um é melhor do que o outro a ideia aqui não é prescrever que você tem que usar um Ou você tem que usar o outro A ideia é eu te apresentar um pouco das qualidades e das limitações de cada uma das dessas duas tecnologias rest e graphql para te ajudar a pensar melhor sobre elas e a tomar

uma decisão mais calculada sobre quando faz sentido usar qual Vamos explorar um pouco o que exatamente que é uma rest api e quais limitações ela tem porque isso vai nos dizer por que graphql foi criado Já que graphql é uma resposta ao rest rest representational state transfer é um padrão de arquitetura que prescreve uma série de princípios e guidelines para implementar restful apis rest é implementado via http ele é um padrão stateless Ou seja sem Estado cada request é isolado eles são Independentes um do outro R também facilita bastante pra gente o uso de Cash

e os dados são comumente transferidos via Jason ou XML e rest é excelente é o que permitiu a gente chegar onde a gente chegou desde do ano 2000 para cá o ecossistema de rest atingiu o nível de maturidade muito grande Tu consegue fazer uma rest api com praticamente todos os frameworks que existem quase todos os desenvolvedores querem eles saibam disso ou não já interagiram de alguma forma com uma rest api então rest já virou natural para empresas e para desenvolvedores ele é de fato o padrão agora pra gente não ficar tanto no teórico vamos dar

uma olhada em alguns requests rest e entender que tipo de limitações ou problemas a gente pode ter ali pra gente conseguir justificar a existência do graphql vamos imaginar aqui uma situação não tão hipotética em que em determinada tela o front Change me precisa mostrar a foto de perfil dos meus amigos e o nome deles foto perfil e nome de todos os meus amigos de cima a baixo com rest existe duas maneiras que você tipicamente veria isso aqui implementado a primeira maneira é a gente ia dar um Get No nosso próprio user aqui user bar meid

e a gente provavelmente receberia de volta um Jon mais ou menos assim contendo as informações do meu usuário com meu nome a minha profile picture etc um monte de informação que pode ou não ser útil e uma lista de ids de amigos meus com essa lista de ids a gente podia fazer vários outros requests um para cada amigo solicitando a profile picture deles como vocês podem imaginar isso é terrível a performance disso ia ser horrorosa porque a gente ia ter que fazer muitos e muitos e muitos de quests só para pegar uma imagem de cada

pessoa uma solução razoável para isso então ao invés de eu ter que fazer tudo isso seria a gente ter uma API sob medida feita especificamente para esse caso de uso vamos chamar aqui de Friends list e essa api como ela é feita sob medida ela pode retornar exatamente e só aquelas informações que a gente realmente precisa mais nada Graphic surgiu no Facebook e ele surgiu mais mais ou menos por causa desse tipo de problema numa rede como o Facebook é muito relevante não só você saber informação sobre o seu usuário mas também buscar informações sobre

os seus amigos porque lá na timeline vai aparecer posts que seus amigos deram like posts que seus amigos compartilharam eventos que os seus amigos vão é que grupos eles frequentam Facebook também é muito acessado no celular e não sei se vocês se lembram mas lá em 2014 o 3G não era tão bom quanto é hoje em dia então realmente não era muito bom a gente ficar buscando um monte de informação que a gente não precisa também daria um trabalho enorme pra gente fazer uma API do tamanho correto para cas cada caso de uso no frontend

a gente teria que ter uma para posts que os nossos amigos deram like uma para posts que foram compartilhados uma para eventos em que os amigos vão comparecer uma para grupos em que os amigos participam E conforme isso for crescendo isso vai dar mais trabalho pro backend criar end points específicos que Retornam só aquela informação que o frontend precisa e nada mais com a api e os end points crescendo crescendo crescendo também tem o problema de dar manutenção para todo send points e o problema de criar documentação e manter documentação atualizada para todos ess send

points e por isso por causa desses problemas surgiu o graphql graphql significa graph query language graph porque no Facebook a nossa representação aqui de usuários e amigos de usuários tá representada num grafo query language porque é uma linguagem que permite que a gente faça queries específicas para uma API o frontend pode solicitar exatamente o tipo de informação que ele quer e a API vai retornar só aquilo e nada mais em teoria graphql é agnóstico em relação a protocolos mas na prática a maioria das implementações usa também http em graphql a gente vai ter um Skema

que é basicamente um contrato entre os serviços de quais tipos de informação vão ser passados e Qual o formato dessa informação a gente vai ter nossas queries e mutations para solicitar e para alterar informações e aqui Ambos são implementados via post método post do http e a gente vai ter os nossos resolvers que são os responsáveis por buscar e agregar a informação de modo que dê um match com como tá especificado no nosso esquema vamos imaginar que a gente tem esse esquema aqui definido em graphql e nota o usuário ele vai ter amigos que também

são do tipo usuário e o que eu quero deixar bem claro aqui é que o esquema do graphql ele serve como um contrato que o frontend e o backend podem concordar E desde que ambos concordem com esse esquema em específico ele efetivamente funciona como uma membrana entre o frontend e o backend o front não precisa saber como que o back implementa as coisas e o back não precisa saber o que que o front end vai consumir ele não precisa saber como o front end vai consumir essas informações tudo que ele precisa fazer é implementar os

resolvers que retornem a informação nesse formatinho aqui e o que esse esquema vai permitir que a gente faça é que por exemplo eu posso definir aqui uma query dentro dessa query eu posso solicitar pelos meus amigos e dentro do noo dos os nossos amigos eu posso solicitar por exemplo o nome e o e-mail deles e só só as informações que eu preciso desse modo com apenas uma chamada daqui para cá eu posso estar solicitando exatamente o que eu quero nesse caso eu quero os meus amigos o nome e e mail deles e o meu backend

vai me retornar isso e somente isso a gente resolveu o problema de over fetching e a gente também resolveu o problema de precisar de múltiplas chamadas e a gente também resolveu o problema de precisar fazer uma API C para cada necessidade do frontend e embora em teoria pareça aqui tudo perfeito tudo excelente é na prática não é tão fácil assim vamos tentar fazer nossos prós e contras aqui de cada um rest obviamente tem muito mais muito mais maturidade do que Graphic todo mundo sabe rest também rest tem uma Dev Pool muito maior é muito mais

fácil você achar alguém que consiga criar uma p rest do que alguém que consiga de fato criar uma API graphql é muito mas muito mais fácil fazer cashing com rest do que graphql tem gente que diz que é IMP fazer com grafl mas não é impossível só é bem mais complexo o custo inicial para se implementar rest é muito baixo quando comparado com Graphic L para fazer todo o setup de todas as coisas que você precisa para ter um Graphic L decente funcionando no front no backend com todos os resolv e Code Generation é muito

mais complexo é subir um map rest é dois minutinhos em rest a gente tem também o problema de over fetching e a gente tem o problema de precisar fazer múltiplas chamadas entre o Fronte entre o front e o back principalmente se a gente tiver usando serviços diferentes para prover os nossos dados no graphql o seu resolver pode agregar tudo em rest Você vai precisar fazer uma chamada para cada um desses serviços agora vamos lembrar aqui para que que o graf foi criado né É quais os pontos positivos dele primeiro é resolver o problema de overfat

o segundo é resolver o problema de múltiplas chamadas principalmente se a gente tiver lidando com vários data sources eu acho que o terceiro e talvez Último Ponto positivo de Graphic que Na minha opinião é o melhor de todos é que o esima Define um contrato entre o frontend e o backend essa definição permite que os times trabalhem Independentes um do outro o seu frontend provavelmente não vai precisar pedir que o seu backend crie apis novas porque todos os dados todo o esquema já foi acordado entre os dois ou seja o ponto forte de graphql é

que ele nos dá um contrato entre o front e o back E desde que ambos implementem esse contrato tá tudo certo sendo assim para times enormes distribuídos trabalhando em aplicações diferentes que podem ter necessidades diferentes para as interfaces graphql é muito bom nesse caso e os lados negativos de graphql é basicamente tudo que a gente citou aqui de positivo no rest A maturidade dele é bem pior a Dev poool é muito mais difícil de encontrar devs que saibam trabalhar com graphql cashing é mais difícil é muito mais difícil implementar graphql principalmente implementar bem graphql e

o by in o quanto que você precisa para começar a usar essa ferramenta é muito código e é muito trabalho para projetos pequenos e eu diria até que para times pequenos não vale a pena você precisa realmente saber o que que você tá fazendo com Graphic e você precisa na minha opinião realmente ter uma necessidade bem grande de graphql para começar a valer a pena usar graphql e agora vamos olhar umas respostas no Twitter né vamos aqui pra pergunta que eu fiz no Twitter você trabalha num Startup querida com e-commerce tem tem mais ou menos

10.000 clientes tem um app web e um iOS o software vai ser reescrito do zero Você vai preferir usar graphql ou rest E por quê O importante aqui não é a resposta não é se você vai preferir rest ou graphql ou ambos ou nenhum enfim o importante é você conseguir explicar o porquê da sua resposta a primeira resposta aqui é do Sérgio seguiria com mque bem boring rest mais sse para eventos em tempo real maturidade melhor suportado em linguagens diferentes observa ilidade mais fácil mais fácil sustentar a infra em comparação com Graphic maturidade certo facilidade

no sentido de sustentar a ifra a infra e observabilidade mais fácil então perfeito é isso prefere rest e explicou por que ele prefere rest o ncolas deu uma resposta bem grande aqui que eu vou tentar fazer uma espécie de leitura dinâmica barra resumo e salientar uns pontos que eu acho interessante ele perguntou aqui o que que o time conhece tecnologia isso aqui é muito importante a gente falou que a Di Pool do rest é muito maior Pode ser que o time nem saiba usar grafic Como que o time tá organizado isso que também é importante

Se o nosso time for muito distribuído pode ser que Graphic real seja uma resposta melhor e ele tá perguntando o que que faria a gente pular de rest para graphql ele perguntou aqui pô o problema é falta de documentação então talvez você não precise de skima Talvez você precise de swager ele também quer saber se a api precisa de alterações constantes que eu me entender se precisar pode fazer sentido um Graphic Ok você você tem uma API on dem você não precisa sempre ficar mudando as suas specs da api e aqui ele tá argumentando bom

eh se a gente tem uma ap rest e é possível a gente corrigir os problemas dessa P rest sem ter que migrar pro Graphic Talvez seja melhor a gente fazer essas correções por exemplo usando restful adicionando swager do que de fato mudar para graphql só para resolver problemas que podem ser resolvidos no rest e aqui tem um ponto muito legal que ele fala tipo eu acho que em times que front e back são coisas separadas e um não toca no quadrado do outro times que não são full stack acho Graphic a melhor opção então foi

o que a gente falou de definir um esquema e times sem uma comunicação são muito boa ou sem necessidade de comunicação ou que são separados então a resposta do Nicholas aqui ela foi bem completa bem compreensiva e tá totalmente certa perfeita e aí ele termina com por último mas não menos importante escolheria rest pela familiaridade e por sempre ter trabalhado em ambientes full stack esse nome tá muito grande o nosso usuário aqui Devid Lucas respondeu que rest barra depende rest é mais simples todo mundo entende Cash fácil autenticação fácil ecossistema riquíssimo ou seja maturidade Cash

ele também citou ali autenticação legal acho que só mudaria Se o time fosse muito grande ou certos times que não fazem parte da mesma empresa nesse caso grafic seria uma ferramenta para ajudar na comunicação então ele tá exaltando aqui os pontos de esquema e times distribuídos sem ter necessidade de comunicação ah excelente e agora vamos pra última do Takashi o Takashi aqui prefere graphql por causa de um metadados ele estou aqui o esquema do grafic e ele falou que é mais fácil de manter do que uma spec da Open api dois você atende mais use

cases de consumo de dados diferenciados é aquilo que a gente falou de queras complexas tem soluções de Real Time subscriptions diretiva de defer que serve para resolver problema de coordenar multiples requests graphql federation que permite quebrar em múltiplos serviços mas não precisa de colas em uma Gateway manual falou que vantagem do graphql em cima dos metadados é que qualquer API de graphql Tem suporte para isso out of the Box você não precisa ficar configurando um monte de coisa que nem você precisaria com rest ele falou que o modelo do Graphic permite um Cash normalizado e

criar experiências melhores de ux se seguir a spec do relay fala aqui também um pouco sobre fragmentação e manutenibilidade do frontend cita aqui que você pode ter um ganho de observabilidade Porque como você tem um resolver por Field com Open lmage você pode observar isso facilmente em cada resolver você pode observar e por último ele falou aqui que é possível gerar um rest RPC like com os metadados do graphql mas o inverso é muito M complicado vocês podem ver que o Takashi aqui gosta bastante de grafic ele tem várias opiniões sobre grafic e ele consegue

defender muito bem a escolha dele então não tenho comentar a resposta seria excelente também