Comunicação de Microfrontends e Microsserviços: Comparativo entre BFF e API Gateway

Pires, Lucas Pereira; Figueiredo, Elaine Barbosa de

doi:10.22167/2675-6528-202601108

Artigo

10 de agosto de 2026

Comunicação de Microfrontends e Microsserviços: Comparativo entre BFF e API Gateway

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

Mais recentes

Compliance E Esg

11 de setembro de 2026

Inteligência Artificial na Gestão Contratual: Supervisão Humana, Riscos Jurídicos e Governança Algorítmica

Compliance E Esg

11 de setembro de 2026

Rituais de Verificação sob Pressão: Categorias de Ação ESG Relatadas por Grande Grupo Frigorífico Antes e Após Operação Deflagrada Pela Polícia Federal e Seus Desdobramentos, em Passado Recente

Gestão Escolar

11 de setembro de 2026

Liderança Escolar à Luz da Teoria U: um Diálogo com as Lideranças Transformacional e Servidora.

10 de setembro de 2026

Desempenho de Modelos de Machine Learning na Seleção de Ações da Bolsa de Valores Brasileira

10 de setembro de 2026

Precificação Hedônica de Imóveis na Grande Florianópolis: Uso e Comparação de Modelos de “Machine Learning”

Neurociência E Aprendizagem Na Educação

10 de setembro de 2026

A Produção de Memes como Estratégia de Formação Literária e Multiletramentos no Ensino Fundamental Ii

Gestão Tributária

10 de setembro de 2026

Definição de Insumos para Fins de Aproveitamento de Créditos de Pis e Cofins

Gestão Tributária

10 de setembro de 2026

Fiscalização Delegada do ITR: Desestímulo aos Convênios, Reflexos na Arrecadação e Desinteresse Processual da União

10 de setembro de 2026

Governança de Dados e Risco Financeiro no Setor Florestal: Evidências Empíricas em Perspectiva Brasil-Finlândia

Você também pode gostar

Compliance E Esg

11 de setembro de 2026

Inteligência Artificial na Gestão Contratual: Supervisão Humana, Riscos Jurídicos e Governança Algorítmica

O advento da inteligência artificial como tecnologia disruptiva reconfigurou processos econômicos, institucionais e jurídicos, conferindo centralidade à automação contratual na gestão de relações complexas. A automação contratual revelou-se um fenômeno juridicamente não neutro, com opacidade decisória, geração automatizada de cláusulas abusivas e dificuldades de atribuição de responsabilidade, deslocando a elaboração contratual para o domínio jurídico-normativo. O estudo analisou como a inteligência artificial na automação contratual intensificou a colisão entre eficiência tecnológica e segurança jurídica, e em que medida mecanismos de supervisão humana significativa e de governança algorítmica funcionaram como instrumentos de ponderação normativa para preservar princípios do direito contratual brasileiro. A pesquisa adotou abordagem qualitativa de estudo de casos múltiplos, com análise documental de quatro casos paradigmáticos: Moffatt v. Air Canada, United States v. RealPage, Deloitte/DEWR e INSS/TRF-4ª Região, representando os contextos consumerista, concorrencial, consultivo-contratual e administrativo. A análise identificou cinco padrões estruturais recorrentes – opacidade decisória, substituição da racionalidade normativa por inferências probabilísticas, accountability gap, assimetria informacional e incompreensão semântica – que emergiram de forma sistêmica. O desfecho fragmentado do caso RealPage reforçou a conclusão de que a jurisprudência sobre automação decisória permanece em formação. A governança algorítmica eficaz demonstrou exigir a integração de mecanismos de auditabilidade, responsabilização e supervisão humana, conforme as normas ISO 31000, COSO ERM e ISO 37301, como condição necessária à legitimidade dos sistemas automatizados de gestão contratual.

Palavras-chave: Contratos; Governança algorítmica; Inteligência artificial; Segurança jurídica; Supervisão humana.

Compliance E Esg

11 de setembro de 2026

Relatórios de sustentabilidade são amplamente empregados como instrumentos de gestão da legitimidade corporativa, mas sua função como mecanismo de reorganização cognitiva em contextos de crise reputacional permaneceu subexplorada na literatura. O estudo analisou as transformações nas categorias de ação ESG reportadas pela Empresa JBS em seus relatórios anuais de sustentabilidade de 2015 a 2018, período que compreendeu dois anos anteriores e dois anos posteriores à Operação Carne Fraca e seus desdobramentos. O objetivo foi investigar como a organização alterou sua estrutura cognitiva após a crise reputacional, por meio de um de seus sistemas de reporte. Empregou-se um processo de catalogação sistemática de 1.088 práticas relatadas, classificadas por pilar ESG, tema material e categoria de ação. O referencial teórico mobilizou Mary Douglas (1986), Michael Power (1997), Meyer e Rowan (1977) e Edelman (2016) para interpretar os fenômenos observados. Os resultados evidenciaram um crescimento exigido em governança, que coexistiu com o colapso do pilar social, o desaparecimento de categorias substantivas e a substituição de ações voltadas a prêmios por ações que ressignificaram as relações da organização e seu posicionamento no mercado. Além disso, treinamentos de liderança migraram do tema de cultura para compliance, campanhas de comunicação cederam lugar a canais estruturais permanentes, e investidores tornaram-se a audiência de maior crescimento proporcional. Concluiu-se que a sofisticação do esforço de legitimação residiu não no que a empresa necessariamente fez, mas na consistência com que reorganizou quem ela diz ser e para quem, a partir das categorias de ação que relatou.

Palavras-chave: Crise reputacional; ESG; Pensamento institucional; Relatórios de sustentabilidade; Estratégia organizacional.

Gestão Escolar

11 de setembro de 2026

Liderança Escolar à Luz da Teoria U: um Diálogo com as Lideranças Transformacional e Servidora.

A integração de diferentes modelos de liderança mostrou-se um caminho relevante para instituições de ensino que buscaram inovar e alcançar excelência em suas práticas educacionais. Contudo, foram escassas as pesquisas empíricas que investigaram a aplicação da Teoria U na gestão escolar associada às abordagens Transformacional e Servidora, o que configurou uma lacuna na literatura. Este estudo buscou compreender como gestores educacionais perceberam e aplicaram princípios da Teoria U — escuta generativa, presencing e cocriação — em diálogo com as abordagens teóricas da Liderança Transformacional e da Liderança Servidora em suas práticas de gestão. A pesquisa, de natureza qualitativa e exploratória, foi realizada em uma instituição de ensino privada, localizada na cidade de São Paulo, que abrangeu desde a Educação Básica até a Pós-Graduação. Os dados foram coletados por meio de um roteiro de perguntas semiestruturadas, aplicado a sete gestores educacionais, e foram analisados com base na Análise de Conteúdo de Bardin. Os resultados evidenciaram aproximações entre as práticas observadas e os pressupostos teóricos dos modelos estudados, com a escuta destacando-se como a competência que melhor articulou as três abordagens no contexto investigado. Também foram identificadas algumas tensões entre os referenciais teóricos e o cotidiano da gestão. O estudo contribuiu para uma reflexão crítica sobre as possibilidades e os limites da integração desses diferentes modelos de liderança em ambientes escolares, ampliando o debate e oferecendo subsídios relevantes para o fortalecimento do campo da gestão educacional.

Palavras-chave: Análise de Conteúdo; Escuta Generativa; Estudo de Caso; Gestão Escolar; Liderança.

10 de setembro de 2026

Desempenho de Modelos de Machine Learning na Seleção de Ações da Bolsa de Valores Brasileira

O mercado acionário brasileiro, caracterizado por elevada volatilidade e restrições de liquidez, impõe desafios à aplicação de modelos de aprendizado de máquina na previsão de retornos e na construção de estratégias de investimento. O estudo comparou o desempenho preditivo e econômico de modelos de aprendizado de máquina e métodos estatísticos tradicionais na estimação de retornos futuros e na formação de carteiras baseadas em ranking de ativos. Utilizaram-se dados históricos de ações da B3, com variáveis técnicas e financeiras derivadas de preços e volume. Avaliaram-se modelos lineares (Regressão Linear, Ridge, LASSO, Elastic Net), de ensemble (Random Forest, XGBoost, LightGBM) e uma rede neural (Multilayer Perceptron). A avaliação preditiva ocorreu por métricas de erro em conjunto de teste, e a econômica por backtest de estratégias long-only, com custos operacionais baseados no turnover para análise de retornos brutos e líquidos. Os resultados revelaram baixa capacidade preditiva em todos os modelos, com R² negativos e erros elevados. Embora diferenças marginais nas previsões tenham gerado variações no desempenho econômico, estas foram de baixa magnitude e instáveis. O modelo LightGBM obteve o melhor desempenho econômico, mas com ganhos limitados em relação ao benchmark após a inclusão de custos operacionais. Não se observou evidência consistente de geração de retorno ajustado ao risco superior.

Palavras-chave: aprendizado de máquina; backtest; mercado acionário; previsão de retornos; seleção de ativos.

10 de setembro de 2026

Precificação Hedônica de Imóveis na Grande Florianópolis: Uso e Comparação de Modelos de “Machine Learning”

O mercado imobiliário da Grande Florianópolis tem experimentado valorização acelerada, impulsionada pelo crescimento populacional e pela demanda turística e de investimento. Este estudo analisou os determinantes do valor de imóveis residenciais e comparou o desempenho preditivo de modelos de aprendizado de máquina, especificamente Random Forest e Gradient Boosting (XGBoost), com uma regressão por Mínimos Quadrados Ordinários (MQO). Os dados foram coletados via web scraping de dois portais imobiliários em março de 2026, abrangendo os municípios de Florianópolis, São José, Palhoça e Biguaçu, resultando em 8.056 observações válidas após limpeza. Avaliou-se o desempenho dos modelos por meio das métricas R², RMSE e MAPE. O XGBoost apresentou o melhor desempenho preditivo geral (R² = 0,742, RMSE = R$ 927.113), enquanto o Random Forest obteve o menor erro relativo (MAPE = 25,69%). Os principais determinantes do preço identificados foram a área construída, a região de localização e o número de banheiros. Uma análise complementar por segmento de mercado revelou que o MQO dependeu dos valores extremos para sustentar seu ajuste, enquanto os modelos ensemble mantiveram desempenho estável. Concluiu-se que os métodos de aprendizado de máquina são mais robustos para precificação hedônica em mercados imobiliários heterogêneos, especialmente na presença de imóveis atípicos.

Palavras-chave: Ensemble; Imobiliário; Regressão; Residencial; Web Scraping.

Neurociência E Aprendizagem Na Educação

10 de setembro de 2026

A Produção de Memes como Estratégia de Formação Literária e Multiletramentos no Ensino Fundamental Ii

A leitura de obras literárias clássicas apresenta desafios no contexto escolar contemporâneo, devido ao distanciamento entre a linguagem dos textos e o repertório dos estudantes. Investigou-se como a utilização de memes contribuiu para a construção de sentidos na leitura da obra Senhora, de José de Alencar, no Ensino Fundamental II. A pesquisa adotou uma abordagem qualitativa, com caráter de pesquisa participante, e foi desenvolvida com duas turmas de 9º ano de uma escola privada em Volta Redonda, Rio de Janeiro. Os dados foram coletados por meio de questionários e das produções dos estudantes, e analisados à luz da análise de conteúdo. Os resultados indicaram que a utilização de memes favoreceu a aproximação dos alunos com o texto literário, reduziu a resistência inicial e ampliou o engajamento com a leitura. Observou-se, também, o avanço progressivo na compreensão da narrativa, evidenciado pela capacidade de interpretar fatos, analisar personagens, identificar relações implícitas e elaborar posicionamentos críticos. As produções revelaram a articulação entre o conteúdo da obra e o repertório sociocultural dos estudantes, indicando a construção de aprendizagens com significado. Concluiu-se que a integração entre literatura e cultura digital potencializou a mediação pedagógica, contribuindo para a formação de leitores mais ativos e interpretativamente autônomos.

Palavras-chave: aprendizagem significativa; cultura digital; leitura literária; multiletramentos; neurociência.

Gestão Tributária

10 de setembro de 2026

Definição de Insumos para Fins de Aproveitamento de Créditos de Pis e Cofins

O estudo analisou a interpretação e a aplicação da definição de insumos para fins de creditamento do Programa de Integração Social (PIS) e da Contribuição para o Financiamento da Seguridade Social (COFINS) no regime não cumulativo, à luz do entendimento firmado pelo Superior Tribunal de Justiça (STJ) no julgamento do Recurso Especial n.º 1.221.170 (Tema 779). Objetivou-se examinar os limites jurídicos da utilização desses créditos, considerando os critérios de essencialidade ou relevância estabelecidos pela jurisprudência do STJ. Realizou-se pesquisa documental e jurisprudencial, com análise de acórdãos representativos do Conselho Administrativo de Recursos Fiscais (CARF) e do STJ, abrangendo períodos anteriores e posteriores ao Tema 779. Complementarmente, conduziu-se pesquisa bibliográfica e estudos de dois casos concretos do CARF, com abordagem qualitativa, para verificar a aplicação prática dos critérios. Constatou-se que o STJ afastou a aplicação automática da definição de insumo do IPI, consolidando os critérios de essencialidade e relevância. Entretanto, a análise dos julgados do CARF evidenciou que, embora houvesse reconhecimento formal do precedente do STJ, sua incidência foi modulada conforme a natureza da atividade empresarial, mostrando-se mais restritiva para empresas de revenda. Os casos concretos ilustraram que creditamentos de fretes foram tratados de forma distinta, dependendo da vinculação do gasto à produção ou à revenda. Concluiu-se que a definição de insumos permanece um ponto sensível do sistema tributário, e a correta utilização dos créditos demanda análise casuística rigorosa, pautada na observância dos precedentes judiciais e dos limites normativos vigentes, para evitar glosas e penalidades.

Palavras-chave: COFINS; Creditamento; Insumos; PIS.

Gestão Tributária

10 de setembro de 2026

Fiscalização Delegada do ITR: Desestímulo aos Convênios, Reflexos na Arrecadação e Desinteresse Processual da União

O Imposto Territorial Rural (ITR), de competência da União, pode ter sua fiscalização e cobrança delegadas aos Municípios e ao Distrito Federal. Este trabalho examinou a adesão municipal a esses convênios e o impacto na arrecadação, analisou se os entraves processuais para os Municípios remeterem demandas aos órgãos federais desestimulavam a celebração de acordos, e avaliou o interesse processual da União em litígios de ITR sob delegação, à luz da Teoria Eclética da Ação, bem como a efetividade da diretriz constitucional de desestímulo a propriedades improdutivas. A pesquisa utilizou um estudo de caso, com base em dados e relatórios oficiais da Receita Federal do Brasil e referencial doutrinário jurídico. Os resultados indicaram baixa adesão municipal aos convênios, com quase 75% dos municípios sem acordo. A arrecadação do ITR, mesmo integralmente repassada, não justificou os investimentos municipais, e a manutenção da atuação processual pela União desestimulou a continuidade dos ajustes. Verificou-se que a União carecia de interesse processual nessas demandas, dada a ínfima representatividade do ITR na arrecadação federal e a ausência de proveito econômico-financeiro, o que impediu o cumprimento efetivo da diretriz constitucional de desestímulo à improdutividade rural. Concluiu-se que são necessárias modificações legislativas para que o ITR alcance seus objetivos de arrecadação e função social.

Palavras-chave: Arrecadação; Eficiência; Fiscalização; ITR; Municípios.

10 de setembro de 2026

Governança de Dados e Risco Financeiro no Setor Florestal: Evidências Empíricas em Perspectiva Brasil-Finlândia

A fragmentação informacional no setor florestal brasileiro constituiu o ponto de partida desta pesquisa, que investigou como a governança de dados impactou a capacidade analítica, o risco financeiro e a competitividade da gestão florestal, por meio de um estudo comparativo entre Brasil e Finlândia. Submeteram-se 332 documentos, incluindo 307 informativos CEPEA/Esalq/USP (2001–2025) e 25 relatórios setoriais (Bracelpa, ABRAF, Ibá, 2003–2025), a um pipeline de extração automatizado baseado em OCR, mineração de texto e expressões regulares, obtendo-se 13.059 registros estruturados. Realizou-se análise de sensibilidade do Valor Presente Líquido (VPL) e análise de sentimento léxica. Apenas 12,1% dos registros de custo continham Custo Operacional Efetivo preenchido, e nenhum apresentou margem líquida calculável. A incerteza nos dados de entrada oscilou o VPL de um projeto florestal em mais de R$ 20.000/ha, evidenciando a distorção da decisão orientada por dados quando a sofisticação algorítmica não substituiu a qualidade dos dados de origem. A análise de sentimento léxica confirmou a transição dos relatórios setoriais brasileiros de formato estatístico para promocional. Em contraste, o modelo finlandês demonstrou a viabilidade de uma governança integrada, com o inventário florestal consolidado como pilar de inteligência industrial. Os resultados indicaram que o fortalecimento da governança de dados constituiu pré-requisito para a transição do setor para um sistema de planejamento sustentado por evidências.

Palavras-chave: competitividade; fragmentação informacional; inteligência artificial; soberania digital; tomada de decisão.

Inovação

14 de setembro de 2026

Não lemos apenas palavras

Como novos códigos, tecnologias e formas de comunicação ampliam aquilo que precisamos aprender a interpretar Ser alfabetizado costuma ser entendido inicialmente como: reconhecer letras, formar palavras, compreender frases e produzir textos. Durante muito tempo, foi principalmente a partir desse domínio que definimos o que significava saber ler e, consequentemente, participar de diferentes espaços da sociedade. […]

Redes Sociais

14 de setembro de 2026

O efeito da influência no consumo

O que a pesquisa Youpix/Nielsen 2026 mostra sobre o avanço da Creator Economy Em 2025, 80% dos consumidores brasileiros compraram algum produto recomendado por influenciadores. Em 2026, o índice chegou a 81%. A estabilidade em um patamar tão elevado indica que a compra por influência deixou de ser um comportamento restrito a determinados públicos. O […]

Chamada De Artigos

11 de setembro de 2026

Chamada de artigos – Edição Temática Gestão de Pessoas

Submissões abertas de 11/09/2026 a 30/09/2026 Estão abertas as submissões para a Chamada Temática Gestão de Pessoas 2026, da Revista Estratégias & Soluções (E&S). A chamada será organizada em dois fluxos editoriais: Fluxo 1 – Trabalhos finais de destaque do MBA USP/EsalqDestinado aos TCCs do curso de Gestão de Pessoas do MBA USP/Esalq que obtiveram […]

Direito Tributário

09 de setembro de 2026

Entre Sísifo e o tonel das Danaides

A cesta básica, o salário-mínimo e o verdadeiro preço das coisas Na mitologia grega, alguns castigos não se distinguiam pela violência de um único sofrimento, mas pela condenação à repetição. Sísifo deveria conduzir uma enorme pedra até o alto de uma montanha e, quando o esforço parecia finalmente concluído, a pedra escapava e retornava ao […]

Inteligência Artificial

03 de setembro de 2026

O desafio atual da colaboração

Na medida em que o processo criativo começa com a IA, organizações precisam repensar como preservar a construção coletiva das ideias Em pouco mais de três anos, ferramentas de inteligência artificial generativa passaram a ocupar grande parte do trabalho nas organizações, seja para escrever, programar, pesquisar, planejar, analisar ou projetar. A presença já é tão […]

Inteligência Artificial

02 de setembro de 2026

O preço de usar IA sem treinamento

Adoção da tecnologia já alcança 88% das organizações mundiais, enquanto o número de profissionais punidos por usá-la sem preparo dobrou em sete meses No primeiro semestre de 2026, ministrei aulas de inteligência artificial com foco em planilhas, dashboards e apresentações, em Barcelona, na Espanha. Entre meus alunos havia advogados e juízes do Il·lustre Col·legi de […]

Sustentabilidade

28 de agosto de 2026

Como a sustentabilidade está redesenhando os data centers

Economia digital encontra limites físicos e tenta reduzir seu impacto ambiental O crescimento acelerado da infraestrutura digital transforma consumo de energia, disponibilidade hídrica, refrigeração, materiais construtivos e localização em variáveis centrais para o projeto da próxima geração de data centers. Durante boa parte da transformação digital, consolidou-se a percepção de que a computação estava progressivamente […]

Branding

27 de agosto de 2026

O branding que venceu a Copa de 2026

Entre identidade visual, uniformes, tipografia e disputa bilionária por audiência, marketing esportivo nunca esteve tão em evidência A Copa do Mundo de 2026 terminou com a Espanha erguendo a taça pela segunda vez, ao vencer a Argentina por 1 a 0 na prorrogação. O Brasil encerrou a competição na 11ª colocação, eliminado ainda nas oitavas […]

Governança

24 de agosto de 2026

Governança corporativa: entre o controle e a responsabilidade

O que as crises corporativas e os erros cometidos nos casos Enron, FTX e Americanas podem ensinar Uma empresa pode ter conselho de administração, auditoria independente, comitê de auditoria, código de conduta, políticas de compliance e dezenas de mecanismos de controle e, ainda assim, caminhar para o colapso. A pergunta incômoda é: se todos esses […]

Gestão Tributária

01 de setembro de 2026

Reforma tributária e planejamento patrimonial no campo

Eficiência para gerenciar os impostos facilita a governança e permite organizar a sucessão familiar A organização patrimonial rural virou uma medida estratégica diante da reforma tributária no Brasil, que entrou em vigor neste ano. O planejamento das atividades e da gestão do patrimônio rural, por meio de ferramentas como a transição da Pessoa Física para […]

Renata de Gaspari Valdejão Almeida

Inteligência Artificial

05 de agosto de 2026

Dentro da empresa e fora do radar: os riscos da Shadow AI

Segundo a Microsoft, 75% dos profissionais já utilizam inteligência artificial no trabalho sem homologação da empresa O uso da inteligência artificial generativa já faz parte da rotina corporativa. Ferramentas como ChatGPT, Copilot e outras plataformas ajudam profissionais a produzir textos, analisar dados, criar apresentações e acelerar tarefas em praticamente todos os setores. Mas esse avanço […]

Renata de Gaspari Valdejão Almeida

Estrategia

02 de julho de 2026

O futuro como competência

Interesse acadêmico reforça a projeção de cenários como ferramenta essencial para a tomada de decisões Enquanto algumas empresas ainda tentam acertar o próximo passo, outras já trabalham com múltiplos futuros possíveis — e se preparam para todos eles. Mas afinal, o que significa “pensar o futuro”? É tendência, é estratégia ou uma nova competência que […]

Renata de Gaspari Valdejão Almeida

Inovação

Tecnologia

21 de maio de 2026

Corredor Agro SP: inovação, articulação institucional e futuro

Pecege comanda operação executiva das atividades do ecossistema de 400 km que ficou conhecido como Vale do Silício do agro brasileiro Em 2025, além de assumir a gestão do Parque Tecnológico de Piracicaba, o Instituto Pecege também foi designado para comandar a operação executiva das atividades do Corredor de Inovação Agropecuária do Estado, o chamado […]

Educação

27 de abril de 2026

Como transformar um TCC em negócio

Nova gestão do Parque Tecnológico de Piracicaba oferece consultoria a egressos de MBAs O novo diretor de projetos do Parque Tecnológico de Piracicaba (PTP), Alexandre Barreto, costuma dizer que uma das maiores recompensas que já teve na vida foi ver seus orientandos do MBA USP/Esalq estruturarem empresas a partir de seus trabalhos de conclusão de […]

Tecnologia

20 de março de 2026

O repertório humano na era da IA

Pensamento crítico e criatividade são insubstituíveis no trabalho do profissional de marketing A Inteligência Artificial (IA) é capaz de feitos incríveis, mas ainda não possui a capacidade de julgamento, empatia, intuição e criatividade estratégica necessárias para fazer o trabalho de um bom profissional de marketing. Nessa área, é importante saber usar a ferramenta para automatizar […]

Renata de Gaspari Valdejão Almeida

Agronegócio

Inovação

23 de fevereiro de 2026

ESG como estratégia de crescimento em uma cooperativa do RS

Santa Clara equilibra responsabilidade social e ambiental com inovação Fundada em 1911 por imigrantes italianos em Carlos Barbosa, na serra gaúcha, a Cooperativa Santa Clara é um exemplo de que é possível equilibrar o crescimento econômico com a responsabilidade social e ambiental. De uma pequena empresa de produção de queijos, a organização evoluiu para um […]

Renata de Gaspari Valdejão Almeida

Agronegócio

Inovação

22 de janeiro de 2026

Brasil livre de febre aftosa: o que muda para a carne brasileira?

Com um rebanho de mais de 200 milhões de cabeças de gado, o país é atualmente o líder em exportações O Brasil recebeu recentemente, pela primeira vez, a certificação de país livre de febre aftosa sem vacinação, conferida pela Organização Mundial de Saúde Animal (OMSA). O selo fortalece a posição do país como fornecedor de carne confiável para o […]

Renata de Gaspari Valdejão Almeida

Inovação

09 de dezembro de 2025

Inovação: o novo ciclo do Parque Tecnológico de Piracicaba

Instituto Pecege assume a gestão apostando na criação de novos negócios A partir de 2026, o Instituto Pecege assumirá a gestão do Parque Tecnológico de Piracicaba (PTP). Entre suas responsabilidades estarão a administração, operação, manutenção e expansão do parque, além do fomento de atividades de inovação, empreendedorismo e ciência e tecnologia. A escolha foi feita […]

Renata de Gaspari Valdejão Almeida

06 de julho de 2026

Arquitetura de Grande Porte: Gestão de Mudanças DSR-SCRUM

Mônica Alessandra Guerios; Maria do Carmo Assis Todorov Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação. A arquitetura e o urbanismo configuram-se como bases imprescindíveis em um espaço urbano cada vez mais complexo e desafiador, onde a intrínseca conexão entre questões sociais, ambientais e tecnológicas […]