1

Gostaria de esclarecer a arquitetura que eu uso. É a melhor para o meu cenário e acredito que possa ser a melhor para grande parte dos cenários.

Contexto: tenho um e-commerce com algum processamento assíncrono:

  • itens do pedido são calculados por um worker de acordo com informações do cliente (demora de 50ms até vários segundos dependendo do calculo que está sendo feito)
  • Por decisão minha toda a chamada aos correios é feita pelo worker (api dos correios é extremamente instável)

Minha tela de pedidos, carrinho e checkout funciona mais ou menos assim:

  • Carrega a tela com os dados atuais do servidor

  • Cliente abre uma conexão SSE no endpoint /sse/{orderId} com id do carrinho atual

  • Sempre que tem uma atualização no pedido é enviada uma notificação nesse endpoint (ShippingUpdatedEvent, OrderItemUpdatedEvent, ...)

  • O front mostra momentaneamente os dados retornados do evento (novos valores, opções de frete..)

  • Em background o front carrega novamente TODO O PEDIDO como se estivesse carregando a tela pela primeira vez -> aqui previne qualquer dado que tenha sido alterado e não reportado no evento

E por anos usei simplesmente um "evento dispara sincronização completa em background"


Basicamente o que defendo é: nem sempre confie nos eventos (para apps que descartar um campo é proibido), quando chega o evento carregue o dado inteiro novamente (Single Source Of Truth)

Carregando publicação patrocinada...