E-commerce - Operação
O `E-commerce` é o storefront da loja.
Nota de referência para contratos, arquitetura, runbook e organização do workspace. É a camada mais estável da documentação.
Papel do app
O E-commerce é o storefront da loja.
Hoje ele entrega:
- home;
- blog editorial;
- PLP e PDP;
- leitura do catalogo via API interna do proprio projeto;
- carrinho e checkout;
- coleta interna de analytics;
- páginas dinâmicas publicadas pelo painel;
- leitura do template publicado para header, home, footer, tema e mega menu.
Também já consegue trocar a home padrão por uma página dinâmica publicada quando o override da home estiver ativo no template.
Como as páginas dinâmicas entram
O storefront tenta resolver o caminho pedido por runtime.
Ordem prática:
- normaliza o caminho;
- procura no snapshot publicado;
- se não achar, verifica se pertence a uma rota nativa;
- caso contrario, retorna
not_found.
Como o blog entra
O blog segue uma resolução separada do builder genérico.
Rotas:
/e-commerce/blog/e-commerce/blog/[slug]
Leitura prática:
- a listagem usa o índice publicado do blog;
- o detalhe lê o documento publicado do slug;
- comentários e reações consultam documentos próprios.
Como o catalogo entra
Quando NEXT_PUBLIC_DATA_SOURCE=app, a PLP e a PDP passam a ler:
/api/v1/catalog/products/api/v1/catalog/products/[slug]
Leitura pratica:
- o storefront deixa de depender diretamente dos mocks antigos;
- a loja passa a consumir a mesma camada operada pelo painel;
- se a API falhar, o frontend ainda consegue cair no fallback local.
Como o template entra
O app tenta ler storefront-template.published.json.
Se não houver snapshot válido:
- usa fallback interno do próprio storefront.
Override opcional da home
Quando as flags de runtime da home dinâmica estiverem ligadas e o template publicado estiver com home.override.enabled = true:
- o storefront tenta localizar o
slugpublicado definido no template; - se encontrar, renderiza essa página como entrada principal de
/e-commerce; - o header e o footer podem ser mantidos ou ocultados conforme a configuração do override;
- se não houver página válida, o storefront volta para a home padrão.
Como o analytics entra
O storefront inicializa uma camada interna de analytics no próprio layout.
Hoje ela cobre:
- page view;
- heartbeat de sessão;
- cliques em elementos interativos;
- busca pelo header;
- atualização de carrinho;
- andamento de checkout;
- compra concluída.
Se o admin habilitar GTM e/ou GA4, os scripts também passam a entrar a partir da configuração publicada do painel, sem edição manual de código.
Prioridade do tema
- snapshot publicado pelo painel;
- query string explicita para inspecao local;
- defaults internos.
Rotas reservadas
plpcartcheckoutpaginas- padrão de PDP
/<slug>/p
API pública de leitura
Além das páginas visuais, o ecossistema agora expõe uma camada pública em /api/v1 com cache HTTP para leitura de:
- páginas publicadas;
- posts do blog;
- catálogo;
- categorias;
- saúde operacional do runtime.