Lucas Pereira Pires; Elaine Barbosa de Figueiredo

DOI: 10.22167/2675-6528-202601108

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

Resumo

A evolução das arquiteturas web impulsionou a adoção de sistemas distribuídos, como microsserviços e microfrontends, exigindo estratégias eficientes na integração entre as camadas de frontend e backend. Com o objetivo de comparar tecnicamente os padrões arquiteturais Backend for Frontend (BFF) e API Gateway no contexto de aplicações modulares, desenvolveu-se duas Provas de Conceito (PoCs) utilizando Javascript e Docker. A metodologia envolveu a simulação de ambientes de produção com múltiplos microsserviços e microfrontends orquestrados, e a análise baseou-se em métricas quantitativas de complexidade de software, além da avaliação qualitativa da experiência do desenvolvedor e dos trade-offs observados. Os resultados indicaram que o padrão BFF ofereceu maior flexibilidade para regras de negócio específicas de interface, mas elevou a complexidade operacional e a duplicação de infraestrutura. Em contraste, o API Gateway simplificou a gestão de rotas e reduziu a redundância de código, embora tenha apresentado limitações na personalização de políticas de cache. A análise de complexidade de software revelou que, para uma única unidade de serviço, as complexidades foram equivalentes, mas a distinção tornou-se evidente na escala sistêmica, onde a proliferação de instâncias de BFFs introduziu sobrecarga de manutenção e redundância. Concluiu-se que a eficácia das arquiteturas está intrinsecamente ligada à estrutura organizacional e à topologia das equipes de desenvolvimento. Para grandes organizações, uma abordagem híbrida, que integra o API Gateway para tráfego global e o BFF para especificidades de interface, mostrou-se uma estratégia robusta e viável, equilibrando controle global e agilidade para entrega contínua em ecossistemas de software complexos.

Palavras-chave: Arquitetura de software; Camada de agregação; Entrega contínua; Integração de sistemas; Sistemas distribuídos.

1. Introdução

A evolução da Rede Mundial de Computadores transformou drasticamente o desenvolvimento de software, impulsionando a transição de aplicações monolíticas para sistemas distribuídos complexos (Saramago e Pessoa, 2022). Inicialmente, as aplicações web eram caracterizadas por uma arquitetura unificada, onde frontend e backend residiam em uma única base de código. Contudo, o crescimento exponencial da demanda por escalabilidade, agilidade e manutenibilidade levou à adoção de paradigmas mais flexíveis. A decomposição de sistemas em componentes menores e independentes, conforme descrito por Steen e Tanenbaum (2018), tornou-se a norma, prometendo maior resiliência e flexibilidade. Entretanto, essa modularidade intrínseca introduziu novos desafios, especialmente na gestão eficiente da comunicação e integração entre as diversas camadas e serviços.

Nesse cenário, os padrões de microsserviços e microfrontends emergiram como pilares para a construção de aplicações modernas. Microsserviços, popularizados por Fowler e Lewis (2014), fragmentam o backend em serviços autônomos, cada um com responsabilidade única e ciclo de vida independente, fomentando a autonomia de equipes e a entrega contínua. Paralelamente, os microfrontends estendem essa filosofia para a camada de interface do usuário, permitindo que diferentes partes da UI sejam desenvolvidas e implantadas de forma independente por equipes multidisciplinares (Yang, 2019; Pavlenko et al., 2020). Embora essas arquiteturas ofereçam benefícios em agilidade e escalabilidade, elas intensificam a complexidade da integração, pois a interface do usuário precisa orquestrar chamadas a múltiplos serviços de backend, cada um com suas próprias APIs e requisitos de dados.

Para mitigar a complexidade de integração entre microfrontends e microsserviços, surgiram padrões arquiteturais de camada de agregação, notadamente o Backend for Frontend (BFF) e o API Gateway. O BFF, conforme proposto por Newman (2015), consiste em uma camada intermediária dedicada a um tipo específico de cliente ou interface, adaptando as respostas dos microsserviços para atender às necessidades exatas do frontend. Essa especificidade confere grande flexibilidade, permitindo que as equipes de interface personalizem a lógica de agregação e transformação de dados, otimizando o consumo de recursos e a experiência do desenvolvedor. Por outro lado, o API Gateway atua como um ponto de entrada centralizado para todas as requisições de backend, roteando-as para os microsserviços apropriados e aplicando políticas transversais como segurança, autenticação e cache de forma global (Fowler e Lewis, 2014). Sua natureza centralizada simplifica a governança e reduz a redundância de código em preocupações comuns.

A escolha entre BFF e API Gateway não é trivial e possui implicações significativas para a estrutura organizacional e a topologia das equipes de desenvolvimento (Leite et al., 2021; Ahmed e Colomo-Palacios, 2021). Enquanto o BFF favorece a autonomia de equipes e a otimização para interfaces específicas, ele pode introduzir maior complexidade operacional e duplicação de infraestrutura. O API Gateway, por sua vez, simplifica a gestão de rotas e reduz a redundância, mas pode limitar a personalização para necessidades de frontend muito distintas. A ausência de uma análise técnica e empírica detalhada que compare esses padrões em um contexto de aplicações modulares dificulta a tomada de decisão arquitetural informada e a sustentabilidade em ecossistemas de software complexos.

Diante desse cenário, este trabalho se justifica pela necessidade de fornecer uma base comparativa robusta para auxiliar arquitetos e desenvolvedores na seleção da estratégia de integração mais adequada. O objetivo deste artigo é comparar tecnicamente os padrões arquiteturais Backend for Frontend (BFF) e API Gateway no contexto de aplicações modulares, avaliando suas implicações na complexidade de software, na experiência do desenvolvedor e nos trade-offs operacionais observados em ambientes simulados de produção.

2. Material e Métodos

Para atingir o objetivo de comparar tecnicamente os padrões arquiteturais Backend for Frontend (BFF) e API Gateway, este estudo empregou uma abordagem metodológica que combinou pesquisa exploratória, qualitativa, experimental e de observação. A pesquisa exploratória permitiu a investigação inicial das características e desafios inerentes a cada padrão. A natureza qualitativa e de observação focou na experiência do desenvolvedor e nos trade-offs operacionais, enquanto o caráter experimental foi concretizado através do desenvolvimento e avaliação de duas provas de conceito (PoCs). Essas PoCs foram projetadas para simular cenários de integração em aplicações modulares, conforme as abordagens arquiteturais em questão.

O estudo foi conduzido em um ambiente de desenvolvimento simulado, replicando as condições de produção para aplicações modulares que empregam múltiplos microsserviços e microfrontends orquestrados. Embora não houvesse um local físico específico para a execução da pesquisa, o desenvolvimento ocorreu em um período anterior à publicação deste trabalho em 2026. A unidade de análise central consistiu em duas provas de conceito distintas, cada uma representando uma das estratégias de integração: uma implementando o padrão BFF e outra o API Gateway. Todo o código-fonte das implementações foi disponibilizado publicamente em um repositório remoto no GitHub, com ramificações separadas para a arquitetura base e cada PoC.

A padronização do ambiente de desenvolvimento foi crucial para garantir a reprodutibilidade e a consistência dos cenários comparativos. Para isso, utilizou-se a tecnologia de containers Docker, com a orquestração gerenciada por meio de comandos Docker Compose. Essa escolha permitiu isolar as dependências e configurar os ambientes de forma idêntica para ambas as PoCs. A linguagem de programação JavaScript foi selecionada para o desenvolvimento de todos os componentes, incluindo microsserviços, microfrontends e as camadas de integração de cada prova de conceito. A execução ocorreu sobre a plataforma Node.js, utilizando a imagem Docker `node:22-alpine`, minimizando variações que poderiam surgir com a mudança de tecnologias.

Previamente ao desenvolvimento das provas de conceito específicas, implementou-se uma arquitetura base comum para a aplicação de demonstração. Essa estrutura fundamental foi concebida para facilitar a transição entre as duas abordagens de integração, mantendo os demais componentes consistentes. A camada de integração, que seria o foco da comparação, foi inicialmente deixada em aberto, permitindo sua definição posterior em cada PoC. Essa arquitetura base permitiu visualizar as interdependências entre os microfrontends e os microsserviços, estabelecendo um ponto de partida neutro para a avaliação comparativa dos padrões BFF e API Gateway.

No lado do backend da arquitetura base, foram simulados três microsserviços distintos, denominados “sobre”, “linha-do-tempo” e “contato”. Essas aplicações foram desenvolvidas de forma simplificada, utilizando a biblioteca Express.js para prover arquivos JSON fixos. O comportamento desses microsserviços foi projetado para emular requisições de consulta a uma API REST, empregando o método GET do protocolo HTTP. A simplicidade desses serviços garantiu que o foco da pesquisa permanecesse na camada de integração, evitando complexidades desnecessárias no backend que pudessem obscurecer os resultados da comparação entre os padrões arquiteturais.

A interface com o usuário foi implementada seguindo o paradigma de microfrontends, com uma composição no lado do cliente e separação vertical do conteúdo, conforme abordagens descritas por Mezzalira (2021). O desenvolvimento da interface utilizou JavaScript puro, HTML e CSS, sem a dependência de frameworks adicionais. A aplicação “shell” atuou como o ponto de contato inicial para o usuário, sendo responsável por carregar o endereço no navegador e orquestrar as chamadas para as dependências remotas dos demais componentes microfrontends. Essa estrutura modular permitiu a independência no desenvolvimento e implantação das diferentes partes da interface.

Para o carregamento dinâmico dos módulos microfrontends em tempo de execução, a aplicação “shell” manteve um arquivo de registro. Este arquivo JavaScript foi configurado para mapear os caminhos ofertados no endereço da aplicação para os respectivos endereços remotos dos microfrontends. O carregamento de cada componente ocorreu pela importação do módulo correspondente, que expunha uma função de renderização. Essa função recebia como parâmetro o elemento hospedeiro do componente, além de um objeto de variáveis de ambiente contendo as definições de endereço da API para cada componente. Essa abordagem permitiu a alteração dos valores entre as PoCs sem modificar o código do frontend, com as variáveis sendo recuperadas dos arquivos Docker em tempo de deploy.

Na primeira prova de conceito, a integração foi implementada utilizando o padrão Backend for Frontend (BFF), caracterizado por uma camada de integração descentralizada. Duas instâncias de serviços BFF dedicados foram desenvolvidas: `bff-home` e `bff-sobre`. Cada BFF foi especificamente configurado para atender às necessidades de sua respectiva interface, agregando chamadas de diferentes APIs e adaptando as respostas dos microsserviços para o formato exigido pelo microfrontend. A comunicação do frontend foi direcionada para as portas específicas de cada BFF (3051 e 3053), isolando o tráfego e as regras de negócio. Adicionalmente, cada BFF implementou sua própria lógica de caching e limitação de requisições, conferindo flexibilidade e personalização.

A segunda prova de conceito implementou a integração por meio de um API Gateway, centralizando a camada de integração em um único serviço. Este API Gateway atuou como um ponto de entrada unificado para todas as requisições provenientes dos microfrontends, roteando-as para os microsserviços apropriados e retornando as respostas correspondentes. Para sua implementação, utilizou-se a biblioteca `http-proxy-middleware` via gerenciador de pacotes npm, configurando um proxy reverso. A lógica de caching e rate limiting foi aplicada de forma global através de middlewares, antes do redirecionamento do proxy. O frontend, por sua vez, comunicou-se exclusivamente através de uma única porta, simplificando a gestão das variáveis de ambiente na aplicação cliente.

Para enriquecer a análise comparativa entre as duas abordagens arquiteturais, foram aferidas métricas de complexidade de software. Essas aferições quantitativas visaram avaliar atributos do produto, do processo de desenvolvimento e dos recursos empregados (Honglei et al., 2009). Os valores obtidos foram utilizados para estimar o custo de desenvolvimento e manutenção do software em cada cenário. A complexidade ciclomática de McCabe (1976), uma métrica clássica que quantifica os caminhos lógicos de um programa, foi um dos indicadores fundamentais coletados, auxiliando na compreensão da estrutura e do esforço de teste necessário para cada implementação.

As medidas de complexidade foram coletadas a partir de duas fontes distintas, com foco nos valores específicos do código desenvolvido na camada de integração. A primeira fonte utilizada foi o produto SonarQube Cloud (SonarSource, 2026), em sua versão gratuita. A integração com o repositório do código-fonte foi realizada, e análises foram executadas manualmente via linha de comando em diferentes ramificações do repositório. Dessa forma, foram aferidos os valores de complexidade ciclomática e complexidade cognitiva para cada implementação, fornecendo dados objetivos sobre a estrutura interna e a facilidade de compreensão do código.

Adicionalmente, a solução Code Health Meter, desenvolvida por Khalfallah (2026), foi empregada como uma fonte alternativa para medir a saúde do software. Esta ferramenta foi obtida através do gerenciador de pacotes npm e executada diretamente na pasta de integração de cada implementação. Os resultados gerados, incluindo complexidade ciclomática e o tempo estimado de desenvolvimento, foram persistidos no repositório remoto para posterior análise. A combinação dessas duas fontes de métricas permitiu uma avaliação mais abrangente e robusta da complexidade de software associada a cada padrão arquitetural, contribuindo para uma comparação mais detalhada.

A análise dos dados coletados foi realizada de forma quantitativa, comparando as métricas de complexidade de software obtidas para cada prova de conceito. Os valores de complexidade ciclomática e cognitiva, bem como o tempo estimado de desenvolvimento, foram confrontados entre as implementações do BFF e do API Gateway. Além da análise quantitativa, a pesquisa incorporou uma avaliação qualitativa da experiência do desenvolvedor e dos trade-offs operacionais observados durante o processo de implementação e teste. Essa abordagem mista permitiu uma compreensão aprofundada das implicações práticas de cada padrão arquitetural no contexto de aplicações modulares.

3. Resultados e Discussão

A implementação funcional das duas arquiteturas propostas, Backend for Frontend (BFF) e API Gateway, foi concluída com sucesso, estabelecendo uma infraestrutura robusta de microsserviços e microfrontends que serviu como base para a análise comparativa. Os testes de execução confirmaram a viabilidade técnica de ambas as abordagens para a composição de interfaces distribuídas em um ambiente modular. A Tabela 1 apresenta uma síntese das características gerais observadas em cada implementação, servindo como ponto de partida para a discussão aprofundada das implicações e trade-offs.

Tabela 1. Características gerais da implementação

Característica	API Gateway	BFFs
Portas de aplicação	Única: 3000	Múltiplas: 3051, 3053
Duplicação de Código	Baixa	Alta
Acoplamento frontend-backend	Baixo	Alto
Adaptabilidade da resposta	Não	Sim

Fonte: Resultados originais da pesquisa

A análise das características gerais, conforme detalhado na Tabela 1, revela distinções fundamentais entre as abordagens. No que tange às Portas de aplicação, o API Gateway centraliza o acesso em uma única porta (3000), enquanto as implementações de BFFs utilizam múltiplas portas (3051, 3053). Essa diferença tem implicações significativas para a gestão da infraestrutura e a configuração de rede. A utilização de uma única porta para o API Gateway simplifica a configuração de firewalls, balanceadores de carga e o gerenciamento de domínios, reduzindo a complexidade operacional em ambientes de produção. Para equipes de operações, isso se traduz em menos pontos de falha a monitorar e uma superfície de ataque potencialmente menor, conforme discutido por Newman (2015) ao descrever a centralização de preocupações transversais. Em contraste, a abordagem de BFFs, com suas portas múltiplas, reflete uma arquitetura mais descentralizada. Embora isso possa conferir maior autonomia às equipes de desenvolvimento de frontend para gerenciar seus próprios pontos de entrada, também introduz uma complexidade adicional na orquestração de contêineres e na gestão de portas expostas, exigindo uma coordenação mais rigorosa para evitar conflitos e garantir a segurança. A proliferação de portas pode, em cenários de grande escala, aumentar a sobrecarga de manutenção e a complexidade de deploy, um desafio comum em sistemas distribuídos (van Steen & Tanenbaum, 2018).

A Duplicação de Código é outro ponto crítico de diferenciação. O API Gateway demonstrou baixa duplicação de código, uma vez que a lógica de roteamento, autenticação e outras preocupações transversais são centralizadas e aplicadas globalmente através de middlewares. Essa centralização promove a reutilização de código e a consistência, aderindo ao princípio DRY (Don’t Repeat Yourself), o que pode levar a um código mais limpo e fácil de manter. A manutenção de uma única base de código para essas funcionalidades reduz o esforço de desenvolvimento e minimiza a probabilidade de inconsistências ou bugs serem introduzidos em diferentes partes do sistema. Em contrapartida, a implementação de BFFs resultou em alta duplicação de código estrutural. Conforme observado durante o desenvolvimento, arquivos de configuração, definições de middlewares comuns e conexões com serviços de cache (como Redis) precisaram ser replicados em cada instância de BFF. Essa replicação, embora permita a personalização, eleva a complexidade de manutenção da infraestrutura, pois qualquer alteração em uma funcionalidade comum exige atualização em múltiplos repositórios e deploys coordenados. Peltonen et al. (2021) destacam que a complexidade geral da aplicação aumenta com a abordagem de microsserviços, e a duplicação de código em BFFs é um exemplo claro desse aumento, impactando diretamente o custo de desenvolvimento e manutenção do software (Honglei et al., 2009).

O Acoplamento frontend-backend também se manifesta de maneira distinta. O API Gateway apresenta um baixo acoplamento, atuando como um intermediário genérico que roteia requisições sem uma forte dependência das especificidades de cada frontend. Isso significa que mudanças nos microsserviços de backend podem ser isoladas do frontend, desde que o contrato da API no Gateway permaneça estável. Essa característica é benéfica para equipes que trabalham em diferentes camadas, permitindo que evoluam de forma mais independente. Por outro lado, os BFFs exibem um alto acoplamento com o frontend. Cada BFF é projetado especificamente para atender às necessidades de uma ou mais interfaces de usuário, agregando e adaptando as respostas dos microsserviços para o formato exato exigido pelo microfrontend. Essa proximidade entre o BFF e o frontend, embora intencional e vantajosa para a otimização da experiência do usuário, cria uma dependência direta. Mudanças no frontend podem exigir modificações correspondentes no BFF, e vice-versa. Essa abordagem é particularmente alinhada com a ideia de equipes verticais ou “cross-functional” que são responsáveis por um produto de ponta a ponta, desde a interface do usuário até o backend (Ahmed & Colomo-Palacios, 2021; Leite et al., 2021). O padrão BFF, conforme descrito por Newman (2015), é intrinsecamente ligado às necessidades do cliente, o que naturalmente leva a um acoplamento mais forte com a camada de apresentação.

A Adaptabilidade da resposta é talvez a característica mais distintiva e um dos principais motivadores para a adoção do padrão BFF. O API Gateway, por sua natureza genérica, geralmente não oferece adaptabilidade na resposta. Ele atua como um proxy reverso, encaminhando requisições e retornando respostas dos microsserviços diretamente, ou com transformações mínimas e globais. Isso pode resultar em um maior consumo de dados pelo cliente, pois o frontend pode receber mais informações do que realmente necessita para a apresentação, levando a um “over-fetching” de dados. Em contraste, os BFFs oferecem alta adaptabilidade da resposta. Cada BFF pode ser configurado para agregar dados de múltiplos microsserviços, filtrar informações irrelevantes e formatar a resposta de maneira otimizada para o microfrontend específico que o consome. Essa capacidade de personalização é crucial para otimizar o desempenho da interface do usuário e reduzir a carga de processamento no cliente, especialmente em dispositivos móveis ou redes com largura de banda limitada. Abdelfattah e Cerny (2023) discutem a necessidade de preencher as lacunas na comunicação frontend-microsserviço, e a adaptabilidade do BFF é uma solução direta para essa questão, permitindo que o frontend receba exatamente o que precisa, no formato que precisa.

A discussão sobre a adaptabilidade da resposta nos leva a considerar a experiência do desenvolvedor e os trade-offs operacionais. No cenário do API Gateway, a simplicidade na gestão de rotas e a redução da redundância de código são vantagens claras. A equipe de desenvolvimento pode focar na lógica de negócio dos microsserviços e na composição dos microfrontends, sem se preocupar excessivamente com a camada de integração, que é gerenciada de forma centralizada. No entanto, a limitação na personalização de políticas de cache para diferentes consumidores, como observado na implementação da PoC 2, pode se tornar um gargalo de flexibilidade. Se diferentes microfrontends tiverem requisitos de cache distintos, um API Gateway genérico pode não ser capaz de atender a todas as necessidades de forma eficiente, forçando soluções alternativas ou comprometendo o desempenho.

Em contrapartida, a implementação de BFFs, como na PoC 1, oferece maior flexibilidade para regras de negócio específicas de interface, permitindo que cada BFF implemente sua própria lógica de caching e limitação de requisições. Essa granularidade é um benefício significativo para microfrontends com requisitos de desempenho ou segurança muito específicos. Por exemplo, um microfrontend que exibe dados altamente dinâmicos pode ter um cache de curta duração ou nenhum cache, enquanto outro que exibe dados estáticos pode ter um cache de longa duração. Essa capacidade de personalização, no entanto, eleva a complexidade operacional e a duplicação de infraestrutura. Cada BFF é um serviço separado que precisa ser implantado, monitorado e mantido, o que aumenta a sobrecarga para as equipes de operações e a complexidade geral do sistema distribuído. A duplicação de lógica de infraestrutura, como conexões de cache e logs, em cada BFF, é um ponto de atenção que pode levar a inconsistências e dificuldades na depuração em um ambiente de produção.

A próxima etapa da análise envolve as métricas de complexidade de software, que fornecem uma perspectiva quantitativa sobre o esforço de desenvolvimento e manutenção. A Tabela 2 apresenta os valores coletados para a complexidade ciclomática e cognitiva, bem como o tempo estimado de implementação, utilizando as ferramentas SonarQube Cloud (SonarSource, 2026) e Code Health Meter (Khalfallah, 2026).

Tabela 2. Métricas de complexidade da camada de integração

Ferramenta	Métrica	API Gateway	Média	Máximo
SonarQube Cloud (SonarSource, 2026)	Complexidade Ciclomática	53	51,5	53
	Complexidade Cognitiva	24	18,5	19
Code Health Meter (Khalfallah, 2026)	Complexidade Ciclomática	59	56,5	58
	Tempo de implementação	1,24 h	1,40 h	1,48 h

Fonte: Resultados originais da pesquisa

Ao analisar a Complexidade Ciclomática medida pelo SonarQube Cloud, observa-se que o API Gateway apresentou um valor de 53, enquanto os BFFs tiveram uma média de 51.5 e um máximo de 53. A complexidade ciclomática, conforme definida por McCabe (1976), quantifica o número de caminhos lógicos independentes em um programa, sendo um indicador do esforço de teste necessário e da probabilidade de erros. A proximidade desses valores para uma única instância de integração é notável. Isso sugere que, para a lógica intrínseca de roteamento e agregação básica de dados, a complexidade estrutural é similar, independentemente de o padrão ser centralizado (API Gateway) ou descentralizado (BFF). Em outras palavras, o esforço para codificar as regras de negócio de integração para um único ponto de entrada ou para um único BFF é comparável. No entanto, é crucial ressaltar que essa métrica reflete a complexidade do *componente individual*, e não a complexidade *sistêmica* de manter múltiplos componentes. A implicação prática é que, embora um único BFF não seja intrinsecamente mais complexo de codificar do que um API Gateway, a necessidade de desenvolver e manter *múltiplos* BFFs em um sistema maior amplifica a complexidade total do projeto, especialmente em termos de testes de integração e regressão.

A Complexidade Cognitiva, também aferida pelo SonarQube Cloud, apresentou valores de 24 para o API Gateway, e uma média de 18.5 com máximo de 19 para os BFFs. A complexidade cognitiva é uma métrica que busca estimar o quão difícil é para um desenvolvedor entender o fluxo de controle de um código. Valores mais baixos indicam maior facilidade de compreensão e, consequentemente, menor custo de manutenção. A ligeira vantagem dos BFFs (média mais baixa) pode ser atribuída à sua natureza mais focada e específica para o cliente. Cada BFF, ao atender a um microfrontend particular, tende a ter uma lógica mais coesa e menos genérica, tornando-o individualmente mais fácil de entender. Em contraste, o API Gateway, por ser mais genérico e centralizar diversas responsabilidades, pode apresentar um fluxo de controle ligeiramente mais complexo em sua implementação. Contudo, essa diferença é marginal quando se considera uma única instância. A implicação aqui é que, para equipes que trabalham em BFFs, a curva de aprendizado para um componente específico pode ser menor, mas a gestão do conhecimento sobre o *conjunto* de BFFs e suas interações pode se tornar um desafio à medida que o sistema cresce.

As métricas de complexidade ciclomática obtidas pelo Code Health Meter (Khalfallah, 2026) corroboram os achados do SonarQube Cloud, com o API Gateway registrando 59 e os BFFs uma média de 56.5 e um máximo de 58. Embora haja pequenas variações nos valores absolutos entre as ferramentas, como mencionado no material original (SonarQube por vezes atribui complexidade zero a arquivos que o CHM avalia como um), a tendência comparativa permanece consistente: a complexidade de uma unidade de integração é similar entre os padrões. Essa consistência reforça a ideia de que a escolha arquitetural não deve ser baseada apenas na complexidade intrínseca de um único serviço, mas sim no impacto acumulado e nas implicações sistêmicas.

O Tempo de implementação estimado pelo Code Health Meter é uma métrica particularmente reveladora. O API Gateway teve um tempo estimado de 1.24 horas, enquanto os BFFs tiveram uma média de 1.40 horas e um máximo de 1.48 horas. Esses valores, embora pequenos em termos absolutos, indicam que o desenvolvimento de um BFF individual tende a ser ligeiramente mais demorado do que a implementação de um API Gateway. Isso pode ser atribuído à necessidade de configurar cada BFF com sua própria lógica de negócio específica, caching e rate limiting, mesmo que parte da estrutura seja duplicada. Para um sistema com múltiplos microfrontends, onde cada um poderia ter seu próprio BFF, o tempo total de implementação seria o tempo de um BFF multiplicado pelo número de BFFs, mais o overhead de gerenciar a duplicação de infraestrutura. Isso se alinha com a observação de Honglei et al. (2009) de que métricas de complexidade podem ser usadas para estimar o custo de desenvolvimento. A implicação prática é que, embora os BFFs ofereçam maior flexibilidade, essa flexibilidade vem com um custo de desenvolvimento inicial e contínuo que deve ser cuidadosamente ponderado.

A discussão comparativa das implementações das provas de conceito revela que ambas as abordagens são tecnicamente viáveis e funcionais para a integração de microfrontends e microsserviços. A estrutura base comum foi fundamental para facilitar a transição entre as duas abordagens, exigindo apenas a alteração de variáveis de ambiente para o endereço de backend de cada microfrontend. Essa flexibilidade na configuração é um ponto positivo para a adaptabilidade do sistema a diferentes contextos de implantação.

A escolha prévia de adotar a implementação via BFFs, como discutido no material original, oferece maior liberdade de decisão para a equipe de desenvolvimento do microfrontend e seu BFF correspondente na nomeação de recursos e objetos transmitidos. Essa abordagem promove uma maior adaptabilidade e transparência ao cliente sobre o funcionamento das camadas internas do servidor, o que pode ser um requisito importante em certos domínios de negócio. O desacoplamento granular das regras de integração na PoC 1, juntamente com a capacidade de adaptar os dados transmitidos, mesmo que limitados ao formato do estudo, é uma vantagem clara. A especificidade dos BFFs permitiu a implementação de políticas de cache independentes, otimizando o desempenho para cada microfrontend. No entanto, a duplicação de código estrutural, como arquivos de configuração e definições de middlewares comuns, é um desafio significativo. Essa replicação aumenta a complexidade de manutenção da infraestrutura, exigindo a gestão de múltiplos contêineres e portas expostas, o que pode levar a um aumento do custo operacional e da probabilidade de erros.

Em contraste, na PoC 2, o API Gateway demonstrou a capacidade de roteamento via proxy de forma declarativa, reduzindo o custo de manutenção do componente de integração. Essa abordagem centralizada é ideal para equipes de plataforma que são responsáveis por manter uma infraestrutura automatizada para os desenvolvedores do produto (Ahmed & Colomo-Palacios, 2021; Leite et al., 2021). A menor adaptabilidade na nomeação dos caminhos oferecidos ao frontend, dos contratos de requisição e da lógica de caching centralizada, que aplicou a mesma política de tempo de vida para todas as chamadas, pode ser uma limitação. Essa falta de flexibilidade pode representar um gargalo em cenários onde adaptações específicas são cruciais, potencialmente levando a um “over-fetching” de dados pelo cliente, pois o frontend pode receber mais informações do que o necessário.

A observação dos dados de complexidade na Tabela 2, onde o valor de complexidade individual de um BFF se assemelha ao do API Gateway, é um ponto crucial. Isso sugere que a complexidade de codificação de uma unidade de integração não é o fator determinante na escolha entre os padrões. Em vez disso, o custo total de infraestrutura em um sistema baseado em BFFs, que depende da quantidade de intermediários necessários, torna-se o principal driver de complexidade sistêmica. A diluição da responsabilidade da integração nos BFFs, embora ofereça flexibilidade, exige atenção para evitar assimetrias de comportamento na aplicação e garantir a isonomia da interface. É fundamental, por exemplo, manter uma gestão centralizada de autenticação e papéis de acesso, disponibilizada para as equipes verticais do produto, para evitar inconsistências e vulnerabilidades.

O esforço total de implementação, conforme indicado pelo tempo estimado na Tabela 2, tende a ser ligeiramente maior para um BFF individual e deve ser multiplicado pela quantidade de BFFs necessários. Isso significa que, embora um único BFF possa ser mais adaptável, a escala de um projeto com muitos microfrontends pode tornar a abordagem de múltiplos BFFs mais custosa em termos de desenvolvimento e manutenção. A falta de adaptabilidade da resposta no API Gateway, por outro lado, pode resultar em um maior consumo de dados pelo cliente, pois o contrato do microsserviço pode retornar mais dados do que o necessário para a apresentação.

Abdelfattah e Cerny (2023) propõem um método de integração baseado em API Gateway com manuseio de contrato via um novo protocolo com comunicação persistente usando sockets para resolver a necessidade de múltiplos BFFs e a falta de adaptabilidade de um gateway puro. Embora essa abordagem inclua um modelo de consulta sob demanda, ela adiciona a responsabilidade de oferecer adaptadores de resposta para diferentes canais ao microsserviço, o que pode aumentar a complexidade do backend. A necessidade de múltiplos BFFs para diferentes canais, que seria agravada com microfrontends, é um problema que essa solução tenta mitigar, mas com um custo de complexidade transferido para os microsserviços.

Pode-se inferir que o tempo de desenvolvimento, além de ser multiplicado pela quantidade de componentes, seria ainda multiplicado pela quantidade de canais ofertados na abordagem de Abdelfattah e Cerny (2023). No entanto, a abordagem de microfrontends com BFFs dedicados, mantidos por uma mesma equipe no modelo vertical, poderia incluir a responsabilidade de dispor de adaptadores específicos ofertados em um único BFF por componente, simplificando a gestão da complexidade.

Finalmente, é crucial reconhecer que a adoção das abordagens apresentadas não é mutuamente exclusiva. Em projetos de grande porte, com múltiplos componentes em microsserviços, uma estratégia híbrida pode ser a mais robusta. Pode-se definir um catálogo de APIs interno, gerido por uma equipe de plataforma e disponibilizado via API Gateway com regras de autorização bem definidas. Isso permitiria que os componentes visuais em microfrontends interajam diretamente com o gateway para preocupações transversais. Em casos onde uma equipe de desenvolvimento de microfrontend mais complexo necessite de adaptabilidade e personalização específicas, projetos adaptadores no formato de BFFs podem ser definidos de acordo com os requisitos específicos. Esse modelo híbrido equilibra o controle global e a governança centralizada com a agilidade e flexibilidade necessárias para sustentar a entrega contínua em ecossistemas de software complexos e dinâmicos, alinhando-se com as melhores práticas de engenharia de software para equipes e arquiteturas distribuídas (Leite et al., 2021). A decisão final sobre qual padrão ou combinação de padrões adotar deve ser orientada pela estrutura organizacional, a topologia das equipes de desenvolvimento e o nível de autonomia e responsabilidade técnica delegado a cada equipe, em vez de uma solução universalmente superior.

4. Conclusão

Conclui-se que o objetivo foi atingido, comparando tecnicamente os padrões arquiteturais Backend for Frontend (BFF) e API Gateway no contexto de aplicações modulares. A análise avaliou suas implicações na complexidade de software, na experiência do desenvolvedor e nos trade-offs operacionais em ambientes simulados de produção. Os resultados demonstraram que o BFF oferece maior flexibilidade e adaptabilidade da resposta para microfrontends específicos, promovendo autonomia para equipes de frontend. Contudo, essa abordagem introduz maior complexidade operacional e duplicação de infraestrutura. Em contraste, o API Gateway simplifica a gestão de rotas e reduz a redundância de código, sendo ideal para governança centralizada, embora com menor adaptabilidade na personalização de políticas de cache e contratos de requisição. A eficácia de cada arquitetura está intrinsecamente ligada à estrutura organizacional e à topologia das equipes de desenvolvimento, sugerindo que a escolha deve ser orientada pelo nível de autonomia e responsabilidade técnica delegada.

Este estudo, embora robusto, possui limitações inerentes à sua natureza de prova de conceito em ambientes simulados, o que pode não refletir integralmente os desafios de sistemas em larga escala. As métricas de complexidade focaram em componentes individuais, e não na complexidade sistêmica total de múltiplos BFFs. Além disso, a implementação foi restrita a uma única stack tecnológica (JavaScript/Node.js). Para estudos futuros, sugere-se a validação do modelo híbrido em projetos de produção de grande porte, investigando os custos operacionais de longo prazo e a escalabilidade. Seria valioso também explorar a aplicação de outras abordagens de integração e aprofundar a análise do impacto de diferentes estruturas organizacionais na adoção e sucesso desses padrões.

Referências Bibliográficas

Abdelfattah, A; Cerny, T.

Ahmed, W; Colomo-Palacios, R. 2021. Team Topologies in Software Teams: A Multivocal Literature Review. International Conference on Computational Science and Its Applications 21(9): 272-282.

Fowler, M.; Lewis, J. 2014. Microservices. Disponível em: <https://martinfowler.com/articles/microservices.html>. Acesso em: 08 out. 2025.

Honglei, T; Wei, S; Yanan, Z. 2009. The Research on Software Metrics and Software Complexity Metrics. 2009 International Forum on Computer Science-Technology and Applications: 131-136.

Khalfallah, H.B. 2026. Code Health Meter: A Quantitative and Graph-Theoretic Foundation for Automated Code Quality and Architecture Assessment. Association for Computing Machinery 35(4).

Leite, L; Pinto, G; Kon, F; Meirelles, P. 2021. The organization of software teams in the quest for continuous delivery: A grounded theory approach. Information and Software Technology 139.

McCabe, T.J. 1976. A Complexity Measure. IEEE Transactions on Software Engineering SE-2(4): 308-320.

Mezzalira, L. 2021. Building Micro-Frontends. 1ed. O’Reilly Media, Inc. USA.

Newman, S. 2015. Pattern: Backends For Frontends. Disponível em: <https://samnewman.io/patterns/architectural/bff/>. Acesso em: 06 out. 2025.

Pavlenko, A.; Askarbekuly, N.; Megha, S.; Mazzara, M. 2020. Micro-frontends: application of microservices to web front-ends. Journal of Internet Services and Information Security 10(2): 49-66.

Peltonen, S; Mezzalira, L; Taibi, D. 2021. Motivations, benefits, and issues for adopting Micro-Frontends: A Multivocal Literature Review. Information and Software Technology 136.

Saramago, J.; Pessoa, F. 2022. The Evolution of Frontend Architectures: From Monoliths to Micro-Frontends. International Journal of Trend in Scientific Research and Development 6(3): 2324-2334.

SonarSource Sàrl. 2026. Sonar docs: SonarQube Cloud. Disponível em: <https://docs.sonarsource.com/sonarqube-cloud>. Acesso em: 31 mar. 2026.

van Steen, M.; Tanenbaum, A.S. 2018. Distributed Systems. 3ed versão 2. Publicado por Maarten van Steen, Países Baixos.

Yang, C; Liu, C; Su, Z. 2019. Research and Application of Micro Frontends. IOP Conference Series: Materials Science and Engineering 490(6).

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