Gerenciamento de Estado Global em Aplicações Web de Alta Frequência com WebSockets e Shared Workers

O Desafio da Sincronização em Tempo Real em Múltiplas Abas

Quando desenvolvemos aplicações web modernas de alta frequência, como dashboards financeiros, sistemas de chat corporativo ou plataformas de monitoramento de infraestrutura, a quantidade de dados recebidos por segundo é avassaladora. Na prática, isso significa que centenas de mensagens chegam ao navegador através de conexões persistentes, conhecidas como WebSockets, mantendo a interface atualizada sem a necessidade de recarregar a página. O problema surge quando o usuário abre a mesma aplicação em duas ou três abas diferentes do navegador. Nesse cenário, cada aba tenta abrir o seu próprio canal de comunicação, duplicando o tráfego de rede, consumindo mais memória e sobrecarregando o servidor com requisições redundantes.

Para resolver esse gargalo operacional, precisamos repensar como o estado global da aplicação é distribuído na máquina do cliente. Em vez de tratar cada aba de forma isolada, a engenharia de software moderna busca centralizar o recebimento dos dados. É aqui que entra o conceito de concorrência no lado do cliente, onde a interface gráfica separa a tarefa de exibição visual da tarefa pesada de comunicação de rede. O objetivo principal é garantir que a aplicação funcione de maneira coesa, rápida e econômica em termos de recursos de hardware, independentemente de quantas abas estejam abertas simultaneamente.

O Papel dos WebSockets na Comunicação Bidirecional

Os WebSockets são protocolos de comunicação que permitem a troca contínua de mensagens entre o navegador e o servidor através de uma única conexão TCP persistente. Na prática, diferente do protocolo HTTP tradicional onde o cliente precisa perguntar ao servidor se há novidades a cada instante, o WebSocket abre um canal direto e duradouro. Isso permite que o servidor envie atualizações assim que elas acontecem, o que é essencial para aplicações que exigem latência mínima, como cotações de bolsa de valores ou placares esportivos em tempo real.

No entanto, a grande vantagem dos WebSockets também traz um desafio complexo de arquitetura quando escalamos para múltiplas instâncias no mesmo navegador. Se um usuário abrir cinco abas de um painel de criptomoedas, o servidor WebSocket precisará lidar com cinco conexões distintas vindas exatamente da mesma pessoa, enviando exatamente os mesmos dados. Isso desperdiça largura de banda, consome ciclos de processamento no servidor para serializar JSON repetidamente e pode estourar os limites de conexões simultâneas suportados pelo backend. Precisamos de uma ponte inteligente entre o navegador e o servidor.

Descentralizando com Shared Workers

Os Shared Workers são scripts executados em segundo plano no navegador, isolados da interface gráfica, que podem ser compartilhados por múltiplas janelas, abas ou até iframes originados do mesmo domínio. Na prática, pense em um Shared Worker como um processo de servidor rodando diretamente na máquina do usuário, agindo como um gerente centralizado. Quando a primeira aba é aberta, ela inicializa o Shared Worker. Se o usuário abrir outras abas em seguida, elas se conectam a esse mesmo trabalhador em vez de criarem novas conexões de rede.

Essa arquitetura transforma o Shared Worker no único responsável por manter a conexão WebSocket ativa com o servidor externo. Quando uma mensagem chega do servidor, o Shared Worker a processa e a distribui para todas as abas conectadas de forma coordenada. Isso reduz drasticamente o consumo de memória RAM e elimina o desperdício de banda de internet, pois o servidor agora enxerga apenas uma conexão por usuário, por mais abas que ele decida manter abertas simultaneamente no navegador.

Implementando a Comunicação entre Abas com Broadcast Channel

Para que o Shared Worker consiga conversar com as diferentes abas abertas pelo usuário, utilizamos a Broadcast Channel API, um mecanismo nativo dos navegadores modernos que permite a comunicação pub-sub entre contextos de execução do mesmo domínio. Na prática, a API funciona como uma estação de rádio interna: o Shared Worker transmite uma mensagem em um canal específico, e todas as abas sintonizadas nesse canal recebem a informação instantaneamente e atualizam seus respectivos estados locais.

A implementação prática exige um código estruturado e resiliente a falhas de rede ou fechamento abrupto de abas. Abaixo, apresentamos um exemplo simplificado de como estruturar a lógica dentro do arquivo do Shared Worker para gerenciar a conexão e despachar os eventos recebidos:

const connections = new Set();
const channel = new BroadcastChannel('app_state_channel');

let ws = new WebSocket('wss://api.exemplo.com/stream');

ows.onmessage = (event) => {
  const data = JSON.parse(event.data);
  // Reenvia a mensagem para todas as abas ouvindo o canal
  channel.postMessage(data);
};

onconnect = (e) => {
  const port = e.ports[0];
  connections.add(port);
  
  port.onmessage = (msgEvent) => {
    // Opcional: lidar com mensagens vindas de abas específicas
    if (ws.readyState === WebSocket.OPEN) {
      ws.send(JSON.stringify(msgEvent.data));
    }
  };
};

Tratando Conflitos de Estado e Recuperação de Falhas

Gerenciar dados em tempo real entre múltiplos contextos exige atenção rigorosa à consistência e à ordem das mensagens recebidas. Na prática, redes móveis e conexões Wi-Fi instáveis podem causar desconexões temporárias do WebSocket gerenciado pelo Shared Worker. Quando a conexão cai, o trabalhador precisa entrar em um modo de reconexão exponencial, tentando se conectar novamente ao servidor sem sobrecarregar a infraestrutura com milhares de tentativas simultâneas por segundo.

Além disso, se uma aba for aberta após um evento crítico já ter ocorrido, ela pode ficar dessincronizada em relação ao restante da aplicação. Para mitigar esse problema, o Shared Worker mantém uma pequena cópia do último estado global conhecido em sua memória interna. Assim que uma nova aba se conecta, ela recebe imediatamente esse instantâneo de dados recentes, garantindo uma experiência de usuário fluida, sem telas em branco ou informações desatualizadas durante a navegação. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Gerenciamento de Estado Global em Aplicações Web de Altíssima Frequência com WebSockets e Arquitetura de Gerenciamento de Estado em Aplicações Web de Alta Frequência com Web Workers.

Considerações Finais

A arquitetura que combina WebSockets e Shared Workers representa um salto significativo na eficiência de aplicações web de alta frequência. Ao transferir o peso da gestão de conexões de rede para um processo centralizado no cliente, aliviamos a infraestrutura do backend e protegemos os recursos de hardware do usuário final contra desperdícios severos. Embora essa abordagem exija um cuidado maior com o tratamento de exceções e a sincronização entre abas, os benefícios em termos de desempenho, escalabilidade e experiência do usuário compensam amplamente a complexidade adicional de engenharia.