O que são WebSockets?

Um WebSocket é uma conexão persistente e bidirecional entre cliente e servidor, que permite a qualquer lado enviar mensagens no instante em que acontecem. O HTTP construiu a web perguntando; os WebSockets a deixaram ao vivo escutando — um upgrade padronizado (RFC 6455) transforma uma request em um canal aberto, e tudo que é tempo real na web — chat, presença, tickers, cursores colaborativos — roda sobre ele.

Principais pontos

Como funciona o handshake de upgrade do WebSocket (HTTP 101)

GET /chat HTTP/1.1                      ← começa como HTTP comum
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← e deixa de ser HTTP aqui
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Daqui em diante: frames mínimos (2–14 bytes de overhead), nas duas direções,
# vs. ~500+ bytes de headers em cada poll HTTP.

A maioria das aplicações não deveria escrever à mão o que vem depois — o idioma de produção é uma camada gerenciada de tempo real em que o socket, os heartbeats e a reconexão são código de outra pessoa:

// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();

// Flutter / Dart — Back4app Flutter SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');

final sub = await liveQuery.client.subscribe(query); // wss:// under the hood
sub.on(LiveQueryEvent.create, (msg) => appendToChat(msg));

// iOS / Swift — Back4app Swift SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
let query = Message.query("room" == "general")

let subscription = query.subscribeCallback   // wss:// under the hood
subscription?.handleEvent { _, event in
  if case .created(let msg) = event { appendToChat(msg) }
}

// Android / Kotlin — Back4app Android SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")

val handling = client.subscribe(query)       // wss:// under the hood
handling.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
  appendToChat(msg)
}

WebSockets vs. todo o resto que move dados

Rodando sockets em produção

Quatro conceitos carregam o peso operacional. Afinidade de sessão: conexões são stateful, então os load balancers precisam manter cada cliente preso ao seu nó de servidor. Fan-out: transmitir uma mensagem para dez mil assinantes espalhados por muitos nós exige um backplane de pub/sub entre servidores — a mensagem viaja de servidor a servidor antes de viajar de servidor a cliente. Backpressure: um celular lento numa rede ruim não pode acumular mensagens sem limite na memória do seu servidor; descarte, agrupe ou desconecte. Liveness: frames ping/pong mais heartbeats de aplicação detectam conexões meio-mortas, e os clientes reconectam com backoff exponencial e jitter, e então reinscrevem seu estado — o passo que implementações ingênuas esquecem. Nada disso é exótico; tudo isso é o motivo de “a gente só abre um socket” virar uma decisão de plataforma.

De mensagens a sincronização: a camada acima

WebSockets crus movem bytes; aplicações querem estado. O degrau acima é a sincronização em tempo real: em vez de inventar tipos de mensagem e contabilidade no cliente, você se inscreve em dados — uma consulta, um documento, um canal — e a camada entrega eventos de mudança precisos, cuida do reconectar-e-atualizar e aplica permissões server-side por assinante. Esse é o modelo de live queries: WebSockets como transporte, um motor de consultas como cérebro. Se o seu código WebSocket está acumulando switch statements sobre tipos de mensagem, você está reconstruindo essa camada à mão.

Casos de uso comuns

• Chat e mensagens — o caso canônico: os dois lados falam, instantaneamente.
• Presença — quem está online, quem está digitando: mensagens minúsculas, alta frequência, nas duas direções.
• Edição colaborativa — documentos e quadros compartilhados, em que posições de cursor e edições fluem continuamente.
• Dashboards ao vivo e tickers — push de números que mudam; SSE também serve quando é só de ida.
• Multiplayer e localização — estado de jogo e marcadores se movendo no mapa, em que latência é o produto.

Você precisa de um socket? Matriz de decisão

E o caminho do meio que a matriz esconde: casos só de servidor para cliente (feeds, notificações) cabem em SSE com bem menos maquinário — a comparação completa de transportes tem seu próprio verbete no registro deste glossário.

Limitações e trade-offs

• Statefulness é o preço do push. Cada conexão aberta é memória de servidor e uma restrição de balanceamento; a ausência de estado do HTTP carregava mais peso do que parecia.
• Redes odeiam conexões longas. Proxies, rádios de celular e laptops fechando a tampa cortam sockets o tempo todo — lógica de reconexão não é caso de borda, é o loop principal.
• A segurança se muda para a conexão. Autentique no connect, valide cada mensagem, aplique autorização por subscription — e sempre wss.
• Cache não existe aqui. Tudo que é enviado por push é computado e entregue por cliente; o CDN não pode ajudar.
• Sincronização feita à mão é uma armadilha. A distância entre “abri um socket” e “sincronização de estado correta, com reconexão e permissões” é onde mora a engenharia de verdade — que é exatamente a camada que vale alugar.

WebSockets no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Sua camada de tempo real é o Live Query: o transporte WebSocket, os heartbeats, a reconexão e o fan-out multi-nó rodam como infraestrutura gerenciada (com o protocolo aberto LiveQuery por baixo), enquanto o seu código se inscreve em consultas e recebe eventos de mudança tipados — com ACLs aplicadas por assinante, para que o tempo real nunca passe por cima do modelo de permissões. As abas de código acima são toda a história do lado do cliente.