Long Polling vs WebSocket: o que escolher para tempo real?

Long Polling vs WebSocket em JavaScript: a batalha épica pelo tempo real

Há muito tempo, numa era em que a internet era lenta e os navegadores eram ingênuos, a única maneira de saber se novos dados apareciam no servidor era apertar F5. Depois veio o AJAX, e aprendemos a puxar o servidor manualmente. Mas e se os dados tivessem que chegar sozinhos, sem a nossa intervenção? Bem-vindo ao mundo das comunicações em tempo real.

Neste artigo, vamos analisar duas abordagens principais que ainda dividem a comunidade de desenvolvedores: o bom e velho Long Polling e o moderno e ousado WebSocket. Escreveremos código em JavaScript, veremos seus mecanismos internos e entenderemos qual ferramenta escolher para o seu próximo projeto. Se você quer entender de uma vez por todas o long polling vs websocket, está no lugar certo.

O problema: como fazer o servidor falar primeiro?

HTTP é um protocolo unidirecional. O cliente (navegador) envia uma requisição, o servidor responde – e pronto, almoço terminado. Mas no mundo real (chats, cotações de ações, notificações), os dados precisam fluir na direção oposta. Por muito tempo, os desenvolvedores se viraram. E aqui estão duas maneiras principais de resolver esse problema.

Long Polling: um truque astuto com o tempo

Imagine que você liga para o suporte técnico e diz: "Vou esperar na linha até que um atendente fique disponível". Você não desliga. É exatamente assim que funciona o Long Polling (também conhecido como "consulta longa").

Como funciona:

\n
• O cliente envia uma requisição HTTP comum.
\n
• O servidor não responde imediatamente se não houver dados. Ele "fica pendurado" e espera.
\n
• Assim que os dados aparecem – o servidor envia a resposta.
\n
• O cliente processa a resposta e imediatamente abre uma nova conexão.
\n

Código no cliente (JavaScript):

function longPoll() {\n  fetch('/updates')\n    .then(response => response.json())\n    .then(data => {\n      console.log('Novos dados:', data);\n      // Inicia imediatamente uma nova consulta\n      longPoll();\n    })\n    .catch(error => {\n      console.error('Erro, reconectando em 2 seg:', error);\n      setTimeout(longPoll, 2000);\n    });\n}\n\n// Iniciar\nlongPoll();

Vantagens:

\n
• Funciona em qualquer servidor e qualquer navegador (até no IE6).
\n
• Não requer protocolos especiais – HTTP puro.
\n
• Atravessa qualquer proxy corporativo e firewall.
\n

Desvantagens:

\n
• Cada mensagem é uma nova requisição HTTP (cabeçalhos, cookies, overhead).
\n
• O servidor mantém muitas conexões abertas (problema C10k – 10 mil clientes).
\n
• A latência é maior que a do WebSocket.
\n

WebSocket: um canal de comunicação permanente

WebSocket é como uma linha aberta entre uma nave espacial e o centro de controle. Você estabelece a conexão uma vez e, a partir daí, ambos os lados podem enviar dados a qualquer momento, sem cerimônias desnecessárias.

Como funciona:

\n
• O cliente inicia um handshake (aperto de mãos) via HTTP.
\n
• O servidor muda o protocolo para ws:// ou wss://.
\n
• Uma conexão bidirecional permanente é estabelecida.
\n
• Os dados são transmitidos em frames – de forma leve e rápida.
\n

Código no cliente (JavaScript):

const socket = new WebSocket('wss://exemplo.com/chat');\n\n// Quando a conexão é aberta\nsocket.onopen = function() {\n  console.log('Conexão estabelecida');\n  socket.send(JSON.stringify({ type: 'saudacao', text: 'Olá, servidor!' }));\n};\n\n// Quando uma mensagem chega\nsocket.onmessage = function(event) {\n  const data = JSON.parse(event.data);\n  console.log('Mensagem do servidor:', data);\n};\n\n// Em caso de erro\nsocket.onerror = function(error) {\n  console.error('Erro WebSocket:', error);\n};\n\n// Ao fechar\nsocket.onclose = function(event) {\n  console.log('Conexão fechada. Código:', even