Este artigo explica como repensar a extensibilidade do Adobe Commerce por meio do Adobe Developer App Builder e substituir grandes partes do PHP personalizado por uma arquitetura mais escalável pode melhorar a escalabilidade, a estabilidade e a manutenção, projetadas para crescimento de longo prazo em um ambiente de produção real.

Introdução

Por anos, a extensibilidade em PHP foi a base da personalização do Adobe Commerce. Mas, à medida que as arquiteturas nativas da nuvem evoluem, surgem alternativas melhores. Em uma implementação recente para um importante provedor europeu de mobilidade e serviços financeiros, substituímos uma parte significativa do desenvolvimento tradicional de módulos do Adobe Commerce pelo App Builder, a plataforma de extensibilidade nativa da nuvem da Adobe. Para isso, utilizamos as ações em tempo de execução (funções sem servidor), os eventos e as APIs para fornecer uma solução mais escalável e sustentável. Este artigo detalha os motivos por trás dessa decisão, a estrutura da arquitetura e os aprendizados.

Visão geral

Uma abordagem de priorização de API com o Adobe Commerce pode ser adotada de forma incremental, avaliando quais recursos seriam mais benéficos de serem executados como aplicativos nativos em nuvem fora da plataforma principal do Adobe Commerce e migrando esses recursos primeiro.

Esse processo levou a um resultado claro:

• ~70% da funcionalidade foi implementada usando o App Builder

• ~30% permaneceram como personalizações PHP nativas do Adobe Commerce

Esse equilíbrio nos permitiu manter a lógica nativa e relacionada ao checkout próxima do Commerce, ao mesmo tempo em que deslocamos tarefas de integração, validação, processamento em segundo plano e orquestração para o App Builder, onde a escalabilidade, isolamento e flexibilidade de implantação se destacam.

A arquitetura resultante (veja o diagrama abaixo, que descreve apenas extensões do App Builder) reflete essa abordagem híbrida: o Adobe Commerce permanece como o núcleo transacional, enquanto o App Builder atua como a base de integração e automação. Essa estratégia conecta identidade (SSO), PIM, ERP, serviços de terceiros e lógica de negócios personalizada por meio de fluxos orientados a eventos e a API Mesh (serviço de orquestração de APIs da Adobe).

Apresentação da arquitetura: como funciona o modelo híbrido

No centro da solução está o Adobe Commerce, fazendo o que faz de melhor: cuidando de catálogos, precificação, carrinhos, checkouts e pedidos. Mantivemos deliberadamente o núcleo transacional limpo e estável, evitando personalizações desnecessárias dentro do tempo de execução do Commerce.

Tudo ao redor desse núcleo, identidade, validação de dados, lógica de disponibilidade, processamento em segundo plano e integrações com terceiros, é tratado por meio do App Builder e da Adobe API Mesh.

A experiência do comprador é toda baseada na nova vitrine do Commerce (desenvolvida com o Edge Delivery Services).

1. Camada de entrada: CDN, vitrine do Commerce e serviço de identidade

Todo o tráfego de visitantes regulares do site chega primeiro à CDN + Edge Delivery Service, que garante desempenho, segurança e entrega global ideais antes que qualquer solicitação alcance os sistemas de backend.

A autenticação é tratada por meio do Keycloak SSO, integrado via:

• Uma integração de SSO do App Builder

• Um módulo PHP padrão do Adobe Commerce do Marketplace para a configuração do SSO

• Essa configuração nos permite combinar a estabilidade da plataforma com a flexibilidade nativa da nuvem.

Principais vantagens desta abordagem

• Gerenciamento centralizado de identidades por meio de um módulo comprovado do Marketplace

  Contamos com uma extensão renomada do Adobe Commerce para configuração de SSO, mapeamento de usuários e fluxos essenciais de autenticação, o que evita o armazenamento da lógica de autenticação personalizada dentro do tempo de execução do Commerce.

• Modificação mínima, segurança máxima

  Em vez de reescrever ou bifurcar o módulo SSO, aplicamos apenas extensões pequenas e direcionadas por meio do App Builder, mantendo o módulo original totalmente atualizável.

• Modelo de integração com foco na API

  Como toda a comunicação depende estritamente das APIs de SSO, não precisamos nos preocupar com detalhes internos de implementação do módulo PHP. Mesmo que o módulo mude internamente, nossa integração permanece estável desde que o contrato da API seja mantido.

2. Camada de orquestração: Adobe API Mesh

No centro da nossa arquitetura de integração está na Adobe API Mesh, que atua como a central de orquestração e comunicação entre todos os sistemas de negócios envolvidos na plataforma:

• Vitrine do Commerce (como front-end)

• Adobe Commerce

• PIM

• ERP

• serviços de validação externa

• e todos os aplicativos do App Builder

Em vez de o frontend do EDS ou o Adobe Commerce estabelecerem integrações diretas e ponto a ponto com cada um desses sistemas, toda a comunicação é roteada por meio da API Mesh.

Principais benefícios de usar a Adobe API Mesh

• Superfície de integração única
  Os sistemas só precisam “conhecer” um ponto de acesso de integração de backend: a Mesh. Cada dependência externa está oculta por trás de um gateway de API unificado.

• Contratos de API consistentes
  Todos os sistemas se comunicam por meio de contratos bem definidos e com controle de versão, o que elimina o acoplamento oculto e reduz drasticamente o risco de quebra de alterações.

• Desacoplamento completo entre sistemas de backend
  PIM, ERP, serviços de validação e aplicativos App Builder ficam totalmente isolados uns dos outros. Qualquer sistema pode evoluir independentemente sem forçar alterações em todo o cenário.

• Segurança e governança centralizadas
  A autenticação, autorização e o controle de tráfego são aplicados no nível da Mesh, não distribuídos em várias integrações personalizadas.

• Base de código simplificada do Commerce
  O Adobe Commerce ou frontend não contém mais uma lógica de integração complexa. Eles simplesmente consomem APIs expostas pela Mesh, mantendo a camada do PHP enxuta e transacional.

3. Serviços do App Builder usados pela vitrine e a camada de SSO

Esses serviços são consumidos diretamente pela vitrine do Commerce e pela camada de SSO, não pelo Adobe Commerce, o que permite que a lógica de negócios crítica funcione independentemente do tempo de execução do Commerce.

Receptor de dados do cliente (SSO → App Builder)

Esse serviço recebe e sincroniza dados do cliente a partir da camada de SSO sem afetar o desempenho da vitrine ou do Commerce. O uso do App Builder garante processamento seguro, escalabilidade assíncrona e elimina a dependência de implantações no Adobe Commerce.

Disponibilidade do produto por cliente (Vitrine → App Builder → PIM)

A disponibilidade do produto é resolvida em tempo real com base no contexto do cliente e nos dados de PIM antes que as solicitações cheguem ao Commerce. O App Builder permite que essa lógica seja escalada de maneira independente e protege o Commerce de uma grande carga de dependência externa.

Validação de dados da empresa (Dun e Bradstreet) (Vitrine → App Builder → Terceiros)

A validação é acionada diretamente da vitrine por meio do App Builder + API Mesh e verificada usando serviços de terceiros, que mantêm a latência e as falhas de serviços externos completamente isoladas do Adobe Commerce.

Mecanismo de redirecionamento de ID externa (Vitrine → App Builder)

O tráfego de entrada de sistemas externos é processado e mapeado por meio do App Builder antes de entrar na vitrine, o que permite a normalização segura do tráfego, o uso de regras de redirecionamento flexíveis e elimina os riscos para o núcleo do Commerce.

4. Pré-renderização da vitrine do Commerce: SEO sem comprometer a UX

A vitrine do AEM Commerce é um aplicativo moderno e orientado por frontend que depende muito do JavaScript para carregar dados do produto no navegador. Embora isso ofereça uma excelente experiência de usuário, enfrentamos um desafio clássico de SPA:

Os rastreadores do mecanismo de pesquisa e os sistemas sem navegador geralmente recebem HTML quase vazios, pois não executam o JavaScript de maneira confiável.

Para resolver esse desafio, implementamos a Pré-renderização do AEM Commerce, uma solução oficial da Adobe criada no App Builder.

Como funciona a pré-renderização em nossa arquitetura

Aplicativo de pré-renderização do App Builder:

• Lê dados do produto diretamente do serviço de catálogo do Adobe Commerce

• Gera páginas HTML totalmente hidratadas com base em modelos predefinidos

• Armazena a saída pré-renderizada em seu próprio armazenamento de blob

A vitrine do Commerce é então configurada para usar esse armazenamento como uma origem de sobreposição. Quando:

• Um rastreador de mecanismo de pesquisa

• Ou qualquer cliente sem navegador solicita o URL de um produto

Ela recebe imediatamente uma resposta do HTML totalmente renderizada com dados reais do produto, sem executar qualquer JavaScript.

Ao mesmo tempo:

• Os usuários regulares ainda recebem a experiência padrão de SPA, com renderização de PDP em tempo real no navegador.

Por que o App Builder é o principal viabilizador

O App Builder é o plano de controle central para todo o processo de pré-renderização. Ele nos permite definir:

• Frequência de busca de dados

• Quais produtos e localidades estão incluídos

• Estrutura HTML e JSON-LD

• Geração de metadados de SEO

Tudo isso pode ser ajustado por meio de pequenas alterações de configuração do App Builder, sem tempo de inatividade para a vitrine principal ou para o Adobe Commerce.

A Adobe também fornece um kit inicial para o aplicativo de pré-renderização do App Builder, o que nos permite preparar a solução para produção em um curto período e obter um aumento imediato na SEO.

Principais benefícios dessa abordagem

• Grande aperfeiçoamento de SEO
  Rastreadores recebem páginas de produto totalmente renderizadas com dados estruturados em vez de HTML em branco.

• Nenhum impacto no desempenho da vitrine
  Os usuários regulares mantêm a experiência de SPA rápida e dinâmica.

• Modelo de implantação sem riscos
  Toda a lógica de pré-renderização é executada fora do Adobe Commerce e do tempo de execução da vitrine.

• Controle completo via App Builder
  Regras de pré-renderização, modelos de dados e agendamentos podem ser ajustados sem reimplantações de plataforma.

5. Sincronização de pedidos e ERP: assíncrona por design

O check-out e a criação de pedidos continuam sendo tratados inteiramente no Adobe Commerce, preservando a integridade dos dados e a consistência transacional. Depois que um pedido é criado, o processo de exportação é atribuído a um exportador de pedidos programados dedicado criado no App Builder.

Esse exportador sincroniza pedidos com o ERP de forma assíncrona, fora do ciclo de vida da vitrine e da solicitação do Commerce.

Principais benefícios dessa abordagem

• O tempo de atividade da vitrine é totalmente independente da disponibilidade do ERP.
  Mesmo que o ERP esteja lento ou temporariamente indisponível, os clientes podem continuar fazendo pedidos sem interrupções.

• Sem bloqueio do check-out devido a falhas no downstream
  A criação de pedidos não depende mais de respostas em tempo real do ERP, eliminando uma grande fonte de riscos de conversão.

• Novas tentativas seguras e fluxo de dados controlado
  O App Builder permite a execução programada, mecanismos de nova tentativa e tratamento de falhas sem afetar o desempenho do Commerce.

• Escalabilidade e implantação independentes
  A sincronização de pedidos pode ser dimensionada com base no volume, sem reimplantações ou efeitos colaterais no desempenho do Adobe Commerce.

Por que não migrar completamente para o App Builder?

Uma das primeiras e mais importantes decisões arquitetônicas foi não tratar o App Builder como um substituto total para os módulos PHP e também não basear tudo no PHP apenas “porque sempre fizemos as coisas assim”.

Em vez disso, cada requisito passou por um filtro simples:

O que ficou no PHP (os 30%)

Nós mantivemos as personalizações do PHP apenas onde elas realmente deveriam ficar:

• Ajustes de check-out e criação de pedidos

• Lógica de preços, carrinho e cotação

• Deep GraphQL e ganchos sensíveis ao desempenho

• Áreas em que a latência deve ser quase zero e totalmente síncrona

Esses são locais onde o acesso direto ao banco de dados, o acoplamento estreito com os elementos internos do Commerce e o controle do ciclo de vida das solicitações ainda são absolutamente justificáveis.

O que foi movido para o App Builder (70%)

Tudo o resto foi removido:

• Identidade e orquestração de SSO

• Validação de cliente e empresa

• Resolução de disponibilidade do produto

• Coordenação do sistema externo

• ERP e integrações de terceiros

• Mecanismos de redirecionamento e automação

• Tarefas em segundo plano e agendadores

Essas são todas áreas em que os módulos PHP historicamente apresentam dificuldades:

• acoplamento rígido

• implantações difíceis

• isolamento inadequado de falhas

• e escalabilidade limitada

Principais benefícios

Ao transferir cerca de 70% da lógica de negócios e integração para o App Builder, nós alteramos o fundamento sob o qual a plataforma é construída, implantada e operada. O impacto foi visível não apenas na qualidade da arquitetura, mas também na velocidade de entrega, estabilidade do sistema e controle de custos a longo prazo.

Implantações independentes

Com o App Builder lidando com a maioria das integrações e fluxos de trabalho de negócios, a maioria das alterações não requer mais uma reimplantação completa do Adobe Commerce. Atualizações de integração, validações e processos em segundo plano podem ser implementados de forma independente, reduzindo drasticamente:

• riscos associados ao lançamento

• janelas de implantação

• despesas gerais de coordenação entre equipes

Isso por si só se tornou um dos maiores ganhos de produtividade nas operações diárias.

Melhor escalabilidade nos pontos mais importantes

Anteriormente, os picos de tráfego em:

• verificações de disponibilidade

• validações da empresa

• ou chamadas de API externas

afetavam diretamente o desempenho do Commerce.

Agora, essas cargas de trabalho são dimensionadas de forma independente no App Builder. Como resultado:

• o desempenho do check-out permanece estável

• os recursos do Commerce são reservados somente para cargas de trabalho transacionais

• e o tráfego imprevisível de terceiros não ameaça mais as taxas de conversão

Isolamento de falha real

Uma das melhorias mais vitais é a contenção de falhas. Quando sistemas de terceiros apresentam latência, degradação ou paralisações:

• o App Builder absorve o impacto

• aplica a lógica de repetição e fallback

• e o Adobe Commerce permanece totalmente operacional

Isso eliminou com eficácia uma série de incidentes que anteriormente levavam à paralisação parcial ou total da vitrine.

Propriedade de código mais clara e responsabilidades bem definidas

A plataforma agora tem limites arquitetônicos claros:

• Adobe Commerce → lógica transacional, check-out, preços, carrinho

• App Builder → integrações, orquestração, validação, processos em segundo plano

Essa separação:

• simplifica a integração de novos desenvolvedores

• reduz as dependências entre equipes

• E evita a erosão gradual do núcleo do Commerce por códigos personalizados com excesso de integração.

Projetado para o futuro

Essa arquitetura híbrida está totalmente alinhada com a estratégia de longo prazo da Adobe baseada em SaaS, com foco na API e com composição de comércio. Ao exteriorizar a lógica mais personalizada:

• as atualizações da plataforma tornam-se mais seguras

• o aprisionamento tecnológico no nível do código é reduzido

• e a solução já está preparada para migrar para o Adobe Commerce as a Cloud Service

Não nos limitamos a resolver apenas as necessidades atuais, mas criamos uma plataforma que está estruturalmente preparada para o que o Adobe Commerce está se tornando.