Resumo Executivo

Ivan Wilhelm; Arthur Pinheiro de Araújo Costa

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

As interfaces de programação de aplicações, amplamente conhecidas pela sigla APIs, e o estilo arquitetural de transferência de estado representacional, denominado REST, estabelecem a base fundamental para a comunicação em ecossistemas de software contemporâneos. A utilização desses padrões permite a criação de sistemas interoperáveis e eficientes, capazes de conectar plataformas distintas por meio de um conjunto de regras bem definidas (Saudate, 2024). No cenário atual do desenvolvimento de sistemas, a adoção de APIs REST tornou-se onipresente, servindo como o mecanismo primordial para a integração de serviços em nuvem, aplicações móveis e sistemas corporativos complexos. A relevância dessa abordagem é potencializada quando integrada à arquitetura de microsserviços, que propõe a decomposição de aplicações monolíticas em componentes menores, leves e independentes, executados em seus próprios contextos e voltados para necessidades específicas de negócio (Lewis e Fowler, 2015). Essa modularização facilita a implantação isolada e o dimensionamento granular de cada funcionalidade, promovendo uma agilidade organizacional superior.

O estilo arquitetural REST define diretrizes para o particionamento de sistemas, determinando como os componentes devem se identificar e se comunicar para minimizar a latência e maximizar a escalabilidade. A ênfase recai sobre uma interface uniforme, na qual os componentes interagem por meio da transferência de representações do estado de recursos (Fielding, 2000). O conceito central dessa arquitetura é o recurso, uma abstração de informação que representa uma entidade nomeável e referenciável por meio de um identificador único. Esses recursos são manipulados através de protocolos padronizados, sendo o protocolo de transferência de hipertexto, ou HTTP, o mais proeminente. A semântica das interações é definida pelos métodos HTTP, que executam ações específicas sobre os recursos. O método GET é empregado para solicitar a representação de um recurso sem alterar seu estado, sendo passível de armazenamento em cache. O método POST é utilizado para a criação de novos estados representacionais no servidor, enquanto o PUT substitui integralmente a representação de um recurso existente. Para modificações parciais, utiliza-se o PATCH, e para a remoção definitiva de um recurso, aplica-se o DELETE (Mozilla, 2025b).

A comunicação entre cliente e servidor no modelo REST é complementada pelos códigos de estado HTTP, que fornecem informações cruciais sobre o resultado das requisições. Esses códigos são organizados em cinco classes distintas: respostas informativas, respostas de sucesso, redirecionamentos, erros do cliente e erros do servidor (Mozilla, 2025a). Por exemplo, o código 200 indica sucesso genérico, enquanto o 201 confirma a criação de um recurso. Erros comuns incluem o 400 para requisições malformadas, o 404 para recursos não encontrados e o 500 para falhas internas no servidor. A correta implementação desses códigos é vital para a robustez e a manutenibilidade das APIs, permitindo que os sistemas consumidores reajam adequadamente a diferentes cenários operacionais (Fielding, 2000).

No mercado de desenvolvimento, o Spring Boot consolidou-se como um dos frameworks mais robustos e amplamente adotados para a construção de APIs REST em ambiente Java, oferecendo uma infraestrutura completa para aplicações de nível empresarial (Saudate, 2024). Paralelamente, surgem alternativas emergentes que buscam oferecer maior leveza e modernidade, como o Shelf, um framework voltado para a linguagem Dart (Google, 2025). A escolha entre uma tecnologia estabelecida e uma opção inovadora não é trivial, pois impacta diretamente o desempenho, a escalabilidade e a eficiência no uso de recursos de hardware. Diante da necessidade de garantir alta disponibilidade e tempos de resposta reduzidos em ambientes produtivos, torna-se imperativo investigar o comportamento técnico dessas ferramentas sob carga. O objetivo desta análise concentra-se na comparação rigorosa de indicadores de desempenho, como o uso de unidade central de processamento, consumo de memória, latência e taxa de transferência, fornecendo subsídios técnicos para a seleção tecnológica em projetos de software de alto impacto.

A metodologia adotada para esta investigação baseia-se em uma abordagem quantitativa experimental, estruturada para isolar variáveis e garantir a reprodutibilidade dos resultados. O experimento consistiu no desenvolvimento de uma API REST de cadastro de usuários em ambas as tecnologias, Spring Boot e Shelf, implementando as mesmas regras de negócio e requisitos funcionais. A aplicação foi projetada para realizar operações fundamentais de criação, leitura, atualização e exclusão, utilizando o banco de dados relacional PostgreSQL para a persistência de dados. Cada usuário cadastrado é composto por três atributos obrigatórios: o primeiro nome, com extensão entre três e 50 caracteres; o sobrenome, também entre três e 50 caracteres; e o endereço eletrônico, que deve possuir entre cinco e 100 caracteres, além de ser único no sistema. A identificação de cada registro é realizada por meio de um identificador único universal, o UUID, garantindo a compatibilidade com arquiteturas distribuídas e microsserviços.

A implementação seguiu os princípios da arquitetura limpa, promovendo a separação entre a lógica de negócio e as preocupações tecnológicas, o que assegura que a comparação de desempenho reflita a eficiência dos frameworks e não deficiências estruturais do código. Para a execução dos testes, utilizou-se a conteinerização por meio da plataforma Docker, permitindo a criação de um ambiente isolado e controlado. A infraestrutura virtualizada foi configurada com quatro núcleos de processamento, seis gigabytes de memória física, dois gigabytes de memória virtual e oito gigabytes de espaço em disco. O ambiente de execução foi estabelecido sobre o sistema operacional macOS, utilizando o framework de virtualização da Apple e a tecnologia Rosetta para a emulação necessária em processadores de arquitetura específica. Essa padronização é essencial para que os dados obtidos sejam comparáveis e isentos de interferências externas provenientes de outros processos do sistema hospedeiro.

O processo operacional de coleta de dados foi realizado com a ferramenta Apache JMeter, uma solução madura e amplamente reconhecida para testes de carga e desempenho (Erinle, 2017). O plano de testes foi desenhado para simular cenários realistas de alta demanda, envolvendo a execução de duas requisições sequenciais por ciclo: a criação de um usuário via método POST e a subsequente recuperação dos dados desse mesmo usuário via método GET, utilizando o identificador gerado dinamicamente. Para garantir a variabilidade dos dados e evitar distorções por cache ou otimizações específicas do banco de dados, foram gerados valores aleatórios para os atributos de cada usuário em cada iteração. O experimento contemplou três níveis de carga distintos: 10.000, 25.000 e 50.000 requisições, todas executadas com uma concorrência de 200 usuários simultâneos.

A preparação do ambiente de teste seguiu as recomendações de identificar critérios de aceitação claros e monitorar continuamente a utilização de recursos (Erinle, 2017). Durante a execução, as métricas de utilização de processador e memória foram extraídas diretamente da interface de monitoramento do Docker, enquanto os indicadores de latência e taxa de transferência foram compilados pelos relatórios estatísticos do JMeter. A execução dos testes ocorreu via linha de comando para minimizar o consumo de recursos pela interface gráfica da ferramenta de teste, prática recomendada para evitar gargalos artificiais e garantir a integridade dos resultados em cenários de estresse (Bayo, 2017). O monitoramento detalhado incluiu a análise do tempo de execução total, a latência média (tempo de resposta), e o throughput, definido como o número de transações processadas por segundo.

Os resultados obtidos revelaram disparidades significativas entre as duas tecnologias avaliadas. No que tange ao tempo total de execução, o Spring Boot demonstrou uma eficiência notavelmente superior. Para a carga de 10.000 requisições, o framework Java concluiu a tarefa em apenas seis segundos, enquanto o Shelf demandou um minuto e 23 segundos. Essa diferença acentuou-se proporcionalmente com o aumento do volume de dados: para 50.000 requisições, o Spring Boot finalizou o processamento em 15 segundos, ao passo que o Shelf necessitou de cinco minutos e 58 segundos. Essa discrepância inicial sugere que o Spring Boot possui uma capacidade de gerenciamento de threads e processamento paralelo muito mais avançada para lidar com altas cargas de trabalho simultâneas.

A análise do consumo de processamento explicita a razão dessa velocidade. O Spring Boot apresentou um uso médio de unidade central de processamento de aproximadamente 363%, indicando uma utilização quase total dos quatro núcleos disponibilizados para o contêiner. Em contrapartida, o Shelf manteve um consumo estável em torno de 29%, independentemente da carga aplicada. Essa observação permite inferir que o Spring Boot é capaz de escalar verticalmente de forma eficiente dentro do ambiente de execução, aproveitando a disponibilidade de múltiplos núcleos para acelerar o processamento das requisições. O Shelf, por outro lado, demonstrou uma limitação na exploração do hardware disponível, o que resulta em uma fila de processamento mais longa e, consequentemente, em tempos de execução estendidos.

No aspecto do consumo de memória, o cenário inverte-se, evidenciando o custo da infraestrutura do Spring Boot. O consumo inicial de memória para que a aplicação Spring Boot estivesse pronta para receber requisições foi de 293,1 MB, valor significativamente superior aos 41,58 MB registrados pelo Shelf. Durante a execução dos testes, o pico de memória do Spring Boot atingiu 425,1 MB na carga máxima, enquanto o Shelf alcançou 81,49 MB. Em termos médios, o Spring Boot consumiu 3,86 vezes mais memória do que o Shelf para processar as mesmas cargas de trabalho. Essa característica é inerente à máquina virtual Java, que exige uma alocação inicial substancial para a gestão de memória, coleta de lixo e carregamento de classes (Saudate, 2024). Embora o Shelf seja mais econômico em termos de recursos de memória, essa economia não se traduziu em desempenho de processamento no experimento realizado.

A latência média, um dos indicadores mais críticos para a experiência do usuário, reforçou a superioridade do Spring Boot em cenários de alta demanda. Para a carga de 50.000 requisições, a latência média do Spring Boot foi de 28,31 ms, enquanto a do Shelf foi de 631,47 ms. Em uma análise consolidada, a latência do Spring Boot foi 17,46 vezes menor do que a apresentada pelo Shelf. Esse dado é fundamental para sistemas que exigem respostas em tempo real ou que possuem acordos de nível de serviço rigorosos. A lentidão observada no Shelf pode comprometer a viabilidade de aplicações que dependem de alta interatividade ou que processam grandes volumes de dados de forma síncrona.

A taxa de transferência, ou throughput, corroborou os achados anteriores. O Spring Boot alcançou uma média de 3377,28 transações por segundo na carga mais elevada, enquanto o Shelf processou apenas 157,98 transações por segundo no mesmo cenário. A capacidade de vazão do Spring Boot mostrou-se 16,96 vezes superior à do Shelf. Essa métrica é vital para o dimensionamento de infraestrutura, pois indica que, para atingir a mesma capacidade de processamento de uma única instância do Spring Boot, seriam necessárias múltiplas instâncias da aplicação em Shelf, o que elevaria a complexidade de gerenciamento e os custos operacionais em um ambiente de produção.

A discussão desses resultados aponta que a escolha do framework deve ser pautada pelo equilíbrio entre disponibilidade de hardware e requisitos de performance. O Spring Boot, apesar de ser mais oneroso em termos de memória RAM, utiliza o processador de forma otimizada, garantindo uma vazão de dados muito superior e uma latência mínima. Essa eficiência é crucial em sistemas de missão crítica onde a velocidade de resposta é o principal diferencial competitivo. O Shelf, embora apresente um perfil de consumo de recursos mais leve, o que poderia sugerir uma vantagem em ambientes com hardware extremamente limitado ou para aplicações de baixa demanda, falhou em escalar seu desempenho quando submetido a uma carga de trabalho intensa. A baixa utilização da CPU pelo Shelf sugere uma arquitetura que, em sua configuração padrão, não favorece o paralelismo massivo exigido por 200 usuários simultâneos.

É importante reconhecer que o desempenho superior do Spring Boot está atrelado à maturidade do ecossistema Java e às constantes otimizações na gestão de concorrência e execução de código em tempo de execução. Frameworks mais recentes como o Shelf podem oferecer vantagens em outros aspectos, como a produtividade do desenvolvedor ou a facilidade de aprendizado, mas, sob a ótica estrita de desempenho técnico em APIs REST de alta carga, os dados experimentais favorecem amplamente a solução consolidada. A implicação prática desses resultados para arquitetos de software é que, para sistemas que preveem crescimento acelerado e necessidade de processar milhares de requisições por segundo, o investimento em hardware para suportar o Spring Boot é justificado pelo ganho expressivo em eficiência e experiência do usuário final.

Limitações desta pesquisa incluem o foco em uma única configuração de hardware e a ausência de testes de escalabilidade horizontal, onde múltiplas instâncias das aplicações poderiam ser balanceadas. Investigações futuras poderiam explorar o comportamento dessas tecnologias em ambientes de nuvem distribuídos, avaliando como a latência de rede e o balanceamento de carga influenciam os resultados. Além disso, a análise de outros padrões de carga, como testes de estresse de longa duração para observar a estabilidade do consumo de recursos ao longo do tempo, enriqueceria a compreensão sobre a robustez de cada framework. A avaliação de aspectos qualitativos, como a manutenibilidade do código e a facilidade de implementação de padrões de segurança, também representaria uma contribuição valiosa para o campo da engenharia de software.

Conclui-se que o objetivo foi atingido, uma vez que a comparação detalhada entre o Spring Boot e o Shelf demonstrou que o Spring Boot é significativamente mais eficiente no processamento de APIs REST sob carga, apresentando uma latência 17,46 vezes menor e uma taxa de transferência 16,96 vezes maior que o Shelf. Embora o Spring Boot demande um consumo de memória superior, sua capacidade de utilizar de forma otimizada os múltiplos núcleos de processamento resulta em um desempenho superior, tornando-o a escolha recomendada para ambientes produtivos que exigem alta disponibilidade e rapidez na resposta às requisições. O Shelf, apesar de sua leveza inicial, apresentou limitações de desempenho que podem comprometer a escalabilidade em cenários de alta demanda, sendo mais adequado para aplicações de menor escala ou com restrições severas de memória onde a velocidade de processamento não seja o fator determinante.

Referências Bibliográficas:

Erinle, Bayo. 2017. Teste de desempenho com JMeter 3: Melhore o desempenho de sua aplicação web. Novatec, São Paulo, SP, Brasil.

Erinle, Bayo. 2017. Teste de desempenho com JMeter 3: Melhore o desempenho de sua aplicação web. Novatec, São Paulo, SP, Brasil.

Fielding, Roy Thomas, 2000. Architectural Styles and the Design of Network-based Software Architectures. Disponível em: <https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>. Acesso em: 11 abr. 2025.

Google. 2025. shelf | Dart package. Disponível em <https://pub.dev/packages/shelf>. Acesso em: 22 mar. 2025.

Lewis, James; Fowler, Martin, 2015. Microsserviços em poucas palavras. Disponível em: <https://www.thoughtworks.com/pt/insights/blog/microservices-nutshell>. Acesso em: 22 mar. 2025.

Mozilla. 2025. Códigos de status de respostas HTTP. Disponível em: <https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Reference/Status>. Acesso em: 20 abr. 2025.

Mozilla. 2025. Métodos de requisição HTTP. Disponível em: <https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Reference/Methods>. Acesso em: 20 abr. 2025.

Saudate, Alexandre. 2024. APIs REST: Seus serviços prontos para o mundo real. Casa do Código, São Paulo, SP, Brasil.

Resumo executivo 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