Posso usar SSE com autenticação baseada em token?

Sim. Como o SSE funciona sobre HTTP, solicitações do mesmo origem enviam cookies automaticamente. Para origens diferentes, passe withCredentials: true no construtor do EventSource para incluir cookies. Para autenticação com token, passe o token como parâmetro de consulta na URL do EventSource — não é bonito, mas o HTTPS o protege durante a transmissão e funciona com todas as implementações do EventSource.

O limite de conexão SSE de 6 é um problema real em 2025?

Apenas em HTTP/1.1. O HTTP/2 multiplexa fluxos em uma conexão única, portanto, o limite não se aplica. A maioria das configurações de hospedagem e CDN modernos padrão para HTTP/2, então isso é basicamente um problema secundário — mas vale a pena confirmar na configuração do servidor. Se você estiver usando HTTP/1.1 por alguma razão, uma solução alternativa é servir SSE de um subdomínio dedicado com seu próprio orçamento de conexões.

Os WebSockets funcionam com funções sem servidor?

A AWS API Gateway tem suporte nativo para APIs WebSocket, mas as chamadas a Lambda são estatais — portanto, você precisa usar DynamoDB (ou algo semelhante) para rastrear IDs de conexão e encaminhar mensagens entre clientes. Os Cloudflare Workers oferecem WebSockets nativamente por meio de Durable Objects. Funciona, mas adiciona uma sobrecarga arquitetural que o SSE em um servidor persistente evita completamente.

O polling longa ainda é usado em produção por empresas sérias?

Sim. Os feeds de atividade em tempo real do GitHub os utilizaram. O Basecamp os usou por anos. Quando a atualização de dados em segundos é aceitável e você deseja a implantação mais simples possível — sem atualizações de protocolo, sem sessões adesivas, sem lógica de reconexão —, o polling é uma escolha totalmente legítima. Não é glamoroso, mas é confiável.

Anúncios incomodam? Ir Sem anúncios Hoje 

WebSockets versus SSE versus Long Polling — Tempo Real Sem o Panico

Atualizado em 20 de maio de 2026

WebSockets, SSE e polling de longa duração têm cada um o seu lugar. Aqui está quando usar cada um — com uma tabela de comparação, exemplos de código e um guia de decisão.

WebSockets vs SSE vs Long Polling — Real-Time Without the Panic 1

ANUNCIADO Remover?

A maioria dos desenvolvedores recorre aos WebSockets por padrão. Isso geralmente está errado.

Não porque os WebSockets sejam ruins — eles são excelentes no que fazem. Mas eles carregam uma sobrecarga real de infraestrutura: sessões fixas nos balanceadores de carga, lógica personalizada de heartbeat, soluções para autenticação e configuração de proxy que funciona bem até alguém abrir seu aplicativo em um escritório corporativo. Para a maioria das necessidades de "real-time", essa sobrecarga não é justificada.

A versão curta: se os dados fluem apenas do servidor para o cliente, use Server-Sent Events (SSE). Se o cliente precisa enviar dados de volta com baixa latência, use WebSockets. Se a frequência de atualização é medida em segundos e você deseja a implantação mais simples possível, o long polling ainda funciona — e não há vergonha nisso.

A comparação

Técnica	Direção	Suporte no navegador	Reconexão automática	Complexidade do balanceador de carga	APIs, microserviços, autenticação cross-domain
Long polling	Servidor → Cliente	Universal	Manual (requisição do cliente)	Nenhum (HTTP padrão)	Atualizações de baixa frequência, intervalos ≥15s
SSE	Servidor → Cliente	Todos os modernos (não IE11)	Integrada (EventSource)	Nenhum (HTTP padrão)	Feed em tempo real, notificações, painéis
WebSockets	Bidirecional	Todos os modernos	Manual (heartbeat personalizado)	Requer sessões fixas	Chat, jogos, edição colaborativa

Long polling

O long polling é uma versão do polling HTTP padrão onde o servidor mantém a requisição aberta até ter algo para retornar — ou até um tempo limite. O cliente envia uma requisição, o servidor espera, retorna a resposta quando dados estão disponíveis e o cliente imediatamente envia a próxima requisição. É um loop disfarçado de chamada de rede.

Isso é realmente adequado para uma variedade de casos de uso:

Bandeiras de notificação — contagens de mensagens não lidas que atualizam a cada 30 segundos não precisam de conexão persistente.
Painéis de administração com frescor relaxado — métricas que atualizam a cada 15 a 60 segundos funcionam bem com polling.
Aplicativos móveis em conexões instáveis — conexões persistentes são interrompidas por gerenciamento agressivo de rede; o polling se reconecta corretamente em cada requisição.
Trás proxies corporativos — muitos proxies corporativos bufferam ou interrompem conexões não padrão. O polling HTTP funciona em todos os lugares, sem exceções.

A limitação de escala é real. Cada requisição mantida aberta ocupa um slot de conexão. Em servidores com threads isso se torna caro; em servidores com loop de eventos (Node.js, Tornado, Go com goroutines) é gerenciável, mas não gratuito. Em dezenas de milhares de usuários simultâneos, os cálculos sobre os recursos do servidor começam a importar.

Server-Sent Events (SSE)

O SSE é a opção que a maioria dos desenvolvedores pula ao ir para WebSockets. Isso é um erro para qualquer caso de uso onde os dados fluem em uma única direção: do servidor para o cliente.

Ele opera sobre HTTP padrão. O servidor define Content-Type: text/event-stream e escreve mensagens delimitadas por quebra de linha no corpo da resposta indefinidamente. A API nativa do navegador EventSource gerencia a reconexão automaticamente — incluindo um Last-Event-ID cabeçalho para que o servidor possa continuar a stream após uma interrupção. Você obtém tipos de eventos nomeados, intervalos de tentativa configuráveis e nenhum biblioteca necessária.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

O que o SSE faz bem:

HTTP padrão — funciona através de balanceadores de carga, proxies reversos e CDNs com zero configuração. Sem sessões fixas.
Reconexão automática — integrada no especificação. Defina o retry: campo na stream para configurar o intervalo; o cliente lida com o resto.
Multiplexação HTTP/2 — remove o antigo limite de 6 conexões por domínio do HTTP/1.1. Se você estiver no HTTP/2 (você deveria estar), isso não é uma preocupação.
Implementação mais simples no servidor — mantenha uma conexão aberta e escreva nele. Sem handshake de protocolo, sem análise de quadros, sem lógica de heartbeat.

A única limitação real: o SSE é unidirecional. Os clientes não podem enviar dados por meio de uma conexão SSE. Na prática, isso raramente é um problema — use requisições POST normais para qualquer coisa que o cliente precise enviar, ao lado da stream SSE para eventos do servidor. Os dois coexistem sem problemas.

O limite do HTTP/1.1 é importante de saber. Navegadores limitam a 6 conexões simultâneas por domínio em todas as abas. Três abas do navegador cada uma consumindo duas streams SSE = limite atingido. O HTTP/2 remove isso por meio de multiplexação. Se você não puder garantir a entrega do HTTP/2 (algumas configurações antigas de CDN, alguns proxies corporativos), mantenha isso em mente.

WebSockets

Os WebSockets são a ferramenta certa quando você realmente precisa de mensagens bidirecionais e de baixa latência. Os casos de uso que justificam a complexidade:

Chat — as mensagens de cada usuário precisam chegar aos outros em tempo quase real. Os WebSockets são a solução padrão por boas razões.
Jogos multijogador — o estado do jogo sincroniza entre os clientes constantemente, muitas vezes em 20 a 60 atualizações por segundo. Nenhuma outra abordagem se aproxima da mesma eficiência por quadro.
Edição colaborativa — a edição em tempo real baseada em CRDT ou OT (Notion, Figma, estilo Google Docs) exige que cada tecla seja propagada com latência mínima.
Terminais de negócios — feeds de preços sub-100ms com submissão de ordens na mesma conexão. Os WebSockets foram criados para isso.

As custos de infraestrutura evitados pelo SSE e pelo polling:

Sessões fixas — as conexões de WebSocket são estatais e vinculadas a um único processo de servidor. Os balanceadores de carga precisam de afiliação de sessão (hash de IP ou baseado em cookie) para redirecionar reconnexões corretamente. Sem isso, um cliente reconectando pode acabar em um servidor sem conhecimento de sua sessão.
Configuração de proxy e CDN — Nginx, HAProxy e Cloudflare todos suportam WebSockets, mas exigem configuração explícita (Upgrade e Connection cabeçalhos, proxy_http_version 1.1 em Nginx). Alguns firewalls corporativos bloqueiam 101 Switching Protocols. Você descobrirá isso em tickets de suporte de usuários em escritórios específicos.
Complexidade de autenticação — os WebSockets não podem definir cabeçalhos personalizados após o handshake inicial. A autenticação por token geralmente significa passar o token na string de consulta (feio, comum) ou na primeira mensagem após a conexão (mais limpo, mas exige lógica de gate no lado do servidor).
Heartbeats — a especificação não exige keepalives. Sem lógica personalizada de ping/pong, você não detectará conexões mortas até que a próxima mensagem falhe. Ou implemente heartbeats ou aceite conexões obsoletas acumulando silenciosamente.

Nenhum desses é um bloqueio — eles são soluções. Eles são complexidades que não existem com SSE ou polling HTTP. Se você estiver escolhendo WebSockets para um feed de notificação ou um painel em tempo real, está pagando esse custo sem motivo.

Como Escolher

Trabalhe com essas opções na ordem correta:

O cliente precisa enviar dados para o servidor com alta frequência, ou a latência abaixo de 200ms importa? Não → pule os WebSockets.
Os dados fluem apenas do servidor para o cliente? Sim → o SSE é quase certamente a escolha correta.
Você está no HTTP/2? Se sim, o SSE não tem limitações significativas para a maioria dos casos de uso. Se não, considere o limite de 6 conexões.
Seu ambiente de implantação é serverless ou está atrás de infraestrutura que não suporta conexões persistentes? O SSE funciona em plataformas de serverless (Vercel, Cloudflare Workers via API de Streams); os WebSockets em serverless exigem adicional plumbing.
A sua frequência de atualização é de 15 segundos ou mais? Long polling. Mantenha simples.

Se você passou por isso e a resposta ainda é WebSockets — ótimo. Agora você os está usando pelo motivo certo, e não pelo padrão inicial.

Depuração de Payloads de Eventos

SSE data: Campos e mensagens de WebSocket quase sempre carregam JSON. Quando você está depurando uma stream mal comportada, colar o payload bruto em IO Tools’ JSON Formatter é a forma mais rápida de ver a estrutura de forma geral — especialmente para objetos aninhados onde um parêntese faltando ou uma vírgula extra mata a análise silenciosamente.