Eric Anderson Martins Cangussu; Anderson Canale Garcia

DOI: 10.22167/2675-6528-202600761

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A crescente complexidade de ecossistemas de software e a demanda por comunicação eficiente entre sistemas heterogêneos impulsionaram a evolução das arquiteturas de API, destacando os desafios de “over-fetching” e “under-fetching” em modelos tradicionais. O estudo objetivou analisar comparativamente a performance de APIs REST e GraphQL em cenários específicos de uso. Para isso, desenvolveram-se dois protótipos de API funcionalmente equivalentes, implementados com PHP 8.2 e Laravel 10, utilizando PostgreSQL 15. Testes de benchmark controlados foram executados com a ferramenta k6 em quatro cenários distintos, avaliando métricas de latência, throughput e tamanho de payload. Os resultados indicaram que o padrão REST apresentou melhor desempenho em operações atômicas e estruturalmente simples, com menor latência e maior throughput. Em contrapartida, o GraphQL demonstrou vantagens significativas em cenários de alta complexidade relacional, reduzindo expressivamente o volume de dados trafegados (payload) e mitigando os problemas de “over-fetching” e “under-fetching”, como evidenciado por uma redução de 84,2% no payload no cenário de hierarquia profunda. Concluiu-se que não existe uma solução universalmente superior, mas sim adequações dependentes do contexto e das características do sistema, e propôs-se um framework de decisão para orientar escolhas arquiteturais.

Palavras-chave: Arquitetura de software; GraphQL; Latência; REST; Sobrecarga.

1. Introdução

A comunicação eficiente entre sistemas heterogêneos distribuídos representa um dos pilares mais críticos no desenvolvimento de arquiteturas de software contemporâneas. A escolha da arquitetura de interface de programação de aplicações (API) é uma decisão estratégica que influencia diretamente a performance, a escalabilidade, a manutenibilidade e a experiência do usuário final de qualquer sistema. Em um cenário onde a interconectividade é constante e a demanda por dados é crescente, a otimização dessas interfaces torna-se imperativa para garantir a robustez e a adaptabilidade das soluções digitais.

Por mais de duas décadas, o padrão arquitetural Representational State Transfer (REST), formalmente proposto por Fielding (2000), consolidou-se como a abordagem dominante para o desenvolvimento de serviços na web. Sua prevalência é atribuída à sua extrema simplicidade, à facilidade de implementação e à sua aderência natural aos métodos e semânticas do protocolo Hypertext Transfer Protocol (HTTP). Essa arquitetura permitiu a criação de sistemas distribuídos robustos e escaláveis, facilitando a integração entre diferentes plataformas e aplicações, e se tornou um modelo de referência para a construção de APIs.

Contudo, a rápida evolução dos ecossistemas digitais, caracterizados pela proliferação de dispositivos móveis e interfaces de usuário cada vez mais dinâmicas e interativas, revelou limitações inerentes ao modelo REST tradicional. Problemas como o “over-fetching”, que consiste no recebimento de um volume excessivo de dados não utilizados pelo cliente, e o “under-fetching”, que exige múltiplas requisições em cascata para obter dados relacionados de uma mesma entidade, tornaram-se mais evidentes (Brito e Valente, 2020). Essas ineficiências resultam em um aumento significativo do consumo de banda de rede, elevam a latência das requisições e complexificam o desenvolvimento e a manutenção das aplicações, impactando negativamente a experiência do usuário. Em resposta a esses desafios, o GraphQL emergiu como uma linguagem de consulta declarativa que aborda essas ineficiências de forma nativa, permitindo que o cliente solicite uma estrutura exata e hierárquica de dados em uma única requisição, otimizando o tráfego de rede (Mikuła e Dzieńkowski, 2020).

A literatura acadêmica recente tem enfatizado a criticidade de comparações empíricas rigorosas para embasar as escolhas tecnológicas, apontando para a existência de “trade-offs” estritamente contextuais entre as abordagens REST e GraphQL. Avaliações aprofundadas de performance demonstram que arquiteturas baseadas em REST podem apresentar superioridade em termos de vazão e latência durante operações simples e isoladas, devido a um menor esforço computacional e “overhead” no lado do servidor (Lawi et al., 2021). Por outro lado, o modelo declarativo do GraphQL oferece uma vantagem competitiva considerável na redução do volume de dados transferidos, também conhecido como “payload”, otimizando o tempo de resposta geral e o consumo de rede em consultas complexas que envolvem relacionamentos profundos entre múltiplas tabelas e agregadores lógicos (Jin e Lloyd, 2025). Apesar do crescente volume de evidências experimentais, observa-se que as decisões arquiteturais no mercado de tecnologia frequentemente ainda se fundamentam em modismos ou preferências subjetivas da equipe de desenvolvimento, em vez de métricas quantitativas associadas à realidade e ao domínio do problema. A adoção de uma solução inadequada pode elevar drasticamente os custos operacionais e degradar a experiência do usuário final, o que justifica a necessidade de consolidar parâmetros comparativos claros e baseados em dados.

Diante da lacuna entre o conhecimento teórico e a prática de mercado, e da necessidade premente de diretrizes balizadas para a tomada de decisão em arquitetura de APIs, este trabalho busca contribuir com um estudo empírico. Assim, o objetivo deste trabalho é analisar comparativamente a performance de APIs REST e GraphQL em cenários específicos de uso, por meio de protótipos funcionalmente equivalentes implementados no framework Laravel com a linguagem Hypertext Preprocessor [PHP].

2. Material e Métodos

A pesquisa caracterizou-se como um estudo aplicado e experimental, com o propósito de gerar conhecimentos práticos para a solução de desafios na área de arquitetura de software, especificamente na escolha entre diferentes arquiteturas de API. Adotou-se uma abordagem quantitativa, onde se manipularam variáveis independentes, representadas pelas arquiteturas REST e GraphQL. Observou-se e analisou-se quantitativamente os efeitos sobre variáveis dependentes, que compreenderam as métricas de performance: latência, throughput e tamanho de payload.

Para a realização do estudo, desenvolveram-se dois protótipos de API funcionalmente equivalentes, construídos sobre a mesma base tecnológica, de modo a isolar a arquitetura de comunicação como a principal variável em análise. Utilizou-se a linguagem PHP versão 8.2, em conjunto com o framework Laravel versão 10, como ambiente de desenvolvimento e execução dos protótipos.

A implementação da API REST empregou recursos nativos do framework Laravel, incluindo rotas de API definidas em `routes/api.php`, controladores (`UserController`, `PostController`) e Eloquent Resources (`UserResource`, `PostResource`, `CommentResource`, `TagResource`). O ORM Eloquent foi utilizado com “eager loading” explícito para evitar o problema N+1 em consultas a dados relacionados.

Para a implementação da API GraphQL, adotou-se a biblioteca Lighthouse PHP. O “schema” foi definido no arquivo `graphql/schema.graphql`, abrangendo tipos como `User`, `Post`, `Comment` e `Tag`. Foram criadas “queries” e “mutations” equivalentes às operações REST, e um “builder” customizado foi desenvolvido para gerenciar filtros complexos em postagens, garantindo a paridade funcional.

O banco de dados escolhido foi o PostgreSQL versão 15, selecionado por sua robustez no tratamento de relacionamentos e consultas complexas, essenciais aos cenários propostos. Para os testes automatizados de correção e o ambiente de desenvolvimento local, utilizou-se SQLite em memória, o que proporcionou maior reprodutibilidade. O ambiente de execução dos testes foi uma máquina local controlada em Blumenau, Santa Catarina.

Os testes de benchmark foram realizados com a ferramenta k6 da Grafana, projetada para simulação de cargas realistas em APIs. Os scripts de teste foram organizados em diretórios específicos para cada arquitetura (`k6/rest/` e `k6/graphql/`). Quatro cenários equivalentes foram definidos para cada API, incorporando “stages” de “ramp-up”, “checks” de status e corpo da resposta, e “thresholds” para latência (p95 e p99) e taxa de erro.

Os cenários de teste representaram padrões de uso comuns em aplicações modernas, baseados em um domínio de blog com entidades como `User`, `Post`, `Comment` e `Tag`. O Cenário 1 focou em operações CRUD em entidade única, utilizando um dataset de 1.000 registros. O Cenário 2 simulou a recuperação paralela de dados relacionais, como um Post com seu Author, Comments e Tags.

O Cenário 3 envolveu buscas massivas com múltiplos filtros lógicos em 10.000 postagens, aplicando filtros simultâneos como “title”, “content”, “author_name” e “tag_name”. O Cenário 4 explorou requisições em estruturas hierárquicas profundas, como um User com suas postagens, comentários e autores, com até três níveis de aninhamento, projetado para avaliar o problema N+1.

Para a simulação de carga, 100 usuários virtuais simultâneos foram aplicados nos cenários onde pertinente, garantindo uma base comparativa. Coletaram-se as seguintes métricas quantitativas para comparação: latência (p95 e p99), throughput em requisições por segundo, e tamanho de payload em quilobytes. Executaram-se cinco rodadas completas de benchmark para cada API em cada cenário para garantir a estabilidade dos dados.

Os resultados brutos foram exportados via k6 no formato JSON e tabulados. A análise e visualização dos dados foram realizadas com Python, utilizando as bibliotecas Pandas para manipulação e Matplotlib para a geração de gráficos comparativos. Testes automatizados de correção e equivalência entre as interfaces foram desenvolvidos com PHPUnit. A pesquisa não envolveu participação de seres humanos, experimentação animal ou risco ambiental, dispensando submissão ao Comitê de Ética.

3. Resultados e Discussão

A execução de cinco rodadas completas de testes de “benchmark” para cada arquitetura de API, REST e GraphQL, em quatro cenários distintos, permitiu uma análise comparativa robusta da performance. Os testes foram configurados com “stages” de 10 segundos para “ramp-up”, 20 segundos de carga constante e 10 segundos para “ramp-down”, simulando condições de uso realistas. Os resultados agregados, obtidos a partir de domínios com 1.000 registros no Cenário 1 e 10.000 postagens no Cenário 3, foram submetidos a uma carga de 100 usuários virtuais simultâneos. Os valores apresentados representam as médias e os respectivos desvios padrão das métricas coletadas, oferecendo uma visão clara do comportamento de cada arquitetura sob diferentes condições de complexidade e carga.

A análise dos dados de latência, especificamente os percentis p95 e p99, revelou uma superioridade consistente do padrão REST em operações caracterizadas por menor complexidade estrutural. Nos Cenários 1 (CRUD User), 2 (Dados Relacionais) e 3 (Filtros e Agregações), a arquitetura REST manteve tempos de resposta significativamente inferiores aos do GraphQL. Por exemplo, no Cenário 1, a latência p95 para REST foi de 19,26 ± 1,58 ms, enquanto para GraphQL foi de 28,09 ± 1,21 ms. Similarmente, no Cenário 4 (Hierarquia Profunda), REST registrou 20,76 ± 2,11 ms para p95, contra 29,89 ± 0,76 ms do GraphQL. Esse padrão de desempenho valida empiricamente os achados de Lawi et al. (2021), que demonstraram um menor “overhead” de processamento para requisições isoladas e diretas no modelo REST, uma característica intrínseca à sua aderência nativa ao protocolo HTTP, conforme descrito por Fielding (2000).

A penalidade de latência observada no GraphQL em operações elementares pode ser atribuída à sua natureza declarativa, que exige uma etapa adicional de interpretação, validação e resolução do “schema” no servidor para cada requisição. Embora essa flexibilidade seja uma vantagem em cenários complexos, ela introduz um custo computacional que se manifesta em tempos de resposta mais elevados para operações mais simples e diretas. A necessidade de processar e validar a estrutura da consulta antes de executá-la contribui para o “overhead” que impacta a latência, especialmente quando a complexidade da requisição não justifica a sobrecarga do processamento do “schema”.

Em contrapartida, a análise do “payload” recebido demonstrou a alta eficiência do GraphQL em mitigar os problemas de “over-fetching” e “under-fetching”, conforme documentado por Brito e Valente (2020). Em todos os cenários testados, a tecnologia GraphQL apresentou uma redução expressiva no volume de dados trafegados pela rede. O ganho mais notável foi observado no Cenário 4 (Hierarquia Profunda), que foi especificamente projetado para expor o problema de N+1 consultas, onde múltiplas requisições seriam necessárias no REST para obter dados relacionados. Nesse contexto, o GraphQL reduziu o tamanho dos dados trafegados em 84,2%, caindo de 1167,18 KB no REST para apenas 183,66 KB.

Essa redução substancial no “payload” do GraphQL em cenários de alta complexidade relacional é um achado crucial, pois otimiza o consumo de banda de rede e o tempo de resposta geral, especialmente em ambientes com largura de banda limitada ou em dispositivos móveis. A capacidade de o cliente especificar exatamente os campos e a estrutura dos dados desejados em uma única requisição elimina o envio de informações desnecessárias, um problema comum no REST. Este resultado corrobora as afirmações de Jin e Lloyd (2025) e Mikuła e Dzieńkowski (2020), que destacam a capacidade do GraphQL de consolidar múltiplas chamadas em uma única requisição aninhada, prevenindo a degradação da performance sob alta complexidade relacional.

Quanto ao “throughput”, que mede a vazão de requisições por segundo, o padrão REST geralmente apresentou um desempenho superior em cenários de menor complexidade. No Cenário 1, REST atingiu 21,95 ± 0,06 requisições por segundo, enquanto GraphQL obteve 21,49 ± 0,03. Contudo, no Cenário 4 (Hierarquia Profunda), o GraphQL superou o REST, registrando 17,86 ± 0,07 requisições por segundo contra 14,81 ± 7,32 do concorrente. Este resultado indica que, embora o REST seja mais eficiente em operações atômicas, a capacidade do GraphQL de consolidar requisições complexas em uma única chamada pode, em certos contextos, resultar em uma vazão superior quando a alternativa REST exigiria múltiplas requisições sequenciais, impactando negativamente o desempenho geral do sistema.

A síntese das métricas empíricas, aliada aos fundamentos teóricos, permitiu a consolidação de um artefato principal de contribuição deste trabalho: um framework de decisão estruturado para apoiar a escolha entre arquiteturas REST e GraphQL. Este framework organiza o problema em um plano bidimensional, considerando a sensibilidade à latência e a necessidade de vazão como um eixo, e a complexidade relacional das consultas como outro. A representação visual desse framework auxilia arquitetos de software e líderes técnicos a tomar decisões balizadas, afastando-se de escolhas baseadas em modismos ou preferências subjetivas.

A interpretação do framework baseia-se na análise conjunta dos eixos. Em ambientes com alta demanda de vazão e baixa complexidade, o uso de REST é favorecido, devido ao menor “overhead” de processamento e menor latência observada. Este cenário é típico para operações atômicas e estruturalmente simples, onde a velocidade de resposta é crítica. Por outro lado, em contextos onde a complexidade relacional é alta e a demanda por dados é flexível, o GraphQL oferece uma vantagem competitiva considerável, especialmente na redução do volume de dados transferidos e na mitigação de múltiplas requisições encadeadas.

Regiões intermediárias indicam contextos em que a decisão depende de fatores adicionais, podendo envolver inclusive a adoção combinada das duas abordagens. O framework destaca três eixos principais de análise. O primeiro eixo, “Vazão e operações atômicas”, enfatiza que em ecossistemas baseados em microsserviços de responsabilidade única, onde o domínio de dados é simples e a volumetria de requisições por segundo (“throughput”) constitui o principal gargalo, a arquitetura REST tende a apresentar melhor desempenho, em função do menor “overhead” de processamento e menor latência, como observado no Cenário 1.

O segundo eixo, “Eficiência de rede e dispositivos móveis”, aborda aplicações voltadas a “frontends” móveis ou executadas sob restrições de rede, onde o custo de transferência de dados torna-se um fator crítico. Nesses casos, o GraphQL mostra-se mais eficiente ao permitir a limitação do “payload”, garantindo que apenas os dados necessários sejam transferidos. Essa característica é vital para otimizar a experiência do usuário em ambientes com conectividade instável ou limitada, reduzindo o tempo de carregamento e o consumo de dados, o que é um diferencial competitivo para aplicações modernas.

O terceiro eixo, “Complexidade relacional e composição de domínios”, é relevante em cenários que envolvem múltiplas entidades e relações complexas, como no Cenário 4. Nesses casos, o GraphQL reduz a necessidade de múltiplas requisições encadeadas, mitigando o problema de N+1 e favorecendo a escalabilidade da aplicação. A capacidade de agregar dados de diversas fontes em uma única requisição simplifica a lógica do cliente e reduz a carga sobre o servidor, tornando-o uma escolha robusta para sistemas com estruturas de dados interconectadas e dinâmicas.

A aplicação do framework proposto permite estruturar a decisão arquitetural de forma sistemática, reduzindo a dependência de escolhas baseadas exclusivamente em preferências individuais ou tendências de mercado. Os resultados obtidos neste estudo apresentam convergência com achados da literatura, especialmente no que se refere ao desempenho superior do REST em cenários de baixa complexidade e alta demanda de processamento, conforme observado por Lawi et al. (2021), que identificam menor latência e maior eficiência em requisições diretas. Por outro lado, os benefícios do GraphQL em cenários mais complexos estão associados à sua capacidade de permitir que o cliente especifique exatamente os dados necessários, reduzindo o volume de informações transferidas (“payload”) e a necessidade de múltiplas requisições (Brito e Valente, 2020).

Esse comportamento está diretamente relacionado à mitigação dos problemas de “over-fetching” e “under-fetching”, especialmente em contextos com alta composição relacional, onde a flexibilidade do GraphQL se torna um diferencial. O presente trabalho contribui ao integrar evidências empíricas e fundamentos teóricos em um modelo estruturado de apoio à decisão. O framework evidencia que REST e GraphQL não devem ser tratados como soluções mutuamente excludentes, mas como abordagens complementares, cuja adequação depende das características específicas do domínio e dos requisitos não funcionais do sistema. É importante ressaltar que os resultados devem ser interpretados à luz das condições experimentais adotadas, considerando o ambiente controlado de execução e os cenários específicos avaliados, o que garante a validade das comparações realizadas.

Em síntese, a pesquisa demonstrou que a escolha entre REST e GraphQL não se baseia em uma superioridade universal de uma arquitetura sobre a outra, mas sim em uma adequação contextual. O REST se destaca em cenários de baixa complexidade e alta demanda por vazão, oferecendo menor latência e maior eficiência em operações atômicas. Em contraste, o GraphQL apresenta vantagens significativas em ambientes de alta complexidade relacional, otimizando o consumo de rede e mitigando problemas de “over-fetching” e “under-fetching” por meio da redução do “payload”. Esses achados respondem ao objetivo do estudo, fornecendo diretrizes empíricas para a tomada de decisão arquitetural em APIs.

4. Conclusão

O presente estudo buscou analisar comparativamente a performance de APIs REST e GraphQL em cenários específicos de uso, por meio de protótipos funcionalmente equivalentes. Verificou-se que o padrão REST demonstrou melhor desempenho em operações atômicas e estruturalmente simples, apresentando menor latência e maior throughput em cenários de baixa complexidade. Em contrapartida, o GraphQL evidenciou vantagens significativas em contextos de alta complexidade relacional, onde se observou uma redução expressiva do volume de dados trafegados, mitigando os problemas de “over-fetching” e “under-fetching”. Essa otimização do “payload” foi particularmente notável no cenário de hierarquia profunda, onde o GraphQL reduziu o tamanho dos dados em 84,2% em comparação com o REST. Os resultados indicam que não existe uma solução universalmente superior, mas sim uma adequação dependente das características do sistema e do contexto de aplicação.

A principal contribuição deste trabalho reside na consolidação de um framework de decisão estruturado, que organiza os fatores críticos para a escolha entre arquiteturas REST e GraphQL, orientando arquitetos de software e líderes técnicos com base em métricas empíricas e características do domínio. Este modelo auxilia na tomada de decisões balizadas, afastando-se de preferências subjetivas e alinhando a solução aos requisitos não funcionais do sistema. Contudo, os resultados devem ser interpretados à luz das condições experimentais controladas e dos cenários específicos avaliados. Para estudos futuros, sugere-se a ampliação da análise para ambientes distribuídos, a variação dos volumes de carga e a exploração de outros contextos arquiteturais, visando expandir a generalização do framework proposto.

Referências Bibliográficas

Brito, G.; Valente, M.T. (2020). REST vs GraphQL: A controlled experiment. IEEE International Conference on Software Architecture 1: 81-91.

Fielding, R.T. (2000). Architectural styles and the design of network-based software architectures. Tese (Doutorado em Ciência da Computação). University of California, Irvine, CA, USA.

Jin, R.; Lloyd, W. (2025). GraphQL vs. REST: Investigating performance and scalability for serverless data persistence. International Conference on Cloud Engineering 1: 1-10.

Lawi, A.; Jackson, H.; Hasanuddin, A. (2021). Evaluating GraphQL and REST API services performance in a massive and intensive accessible information system. Computers 10: 138-150.

Mikula, M.; Dzieńkowski, M. (2020). Comparison of REST and GraphQL web technology performance. Journal of Computer Sciences Institute 16: 309-316.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy