¿Qué son los WebSockets?

Un WebSocket es una conexión persistente y bidireccional entre cliente y servidor que permite a ambos lados enviar mensajes en el instante en que ocurren. HTTP hizo la web preguntando; los WebSockets la hicieron viva escuchando — un upgrade estandarizado (RFC 6455) convierte una solicitud en un canal abierto, y todo lo que es tiempo real en la web — chat, presencia, tickers, cursores colaborativos — viaja sobre él.

Puntos clave

Cómo funciona el handshake de upgrade de WebSocket (HTTP 101)

GET /chat HTTP/1.1                      ← empieza como HTTP común
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← y aquí deja de ser HTTP
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Desde ahora: frames diminutos (2–14 bytes de overhead), en ambas direcciones,
# vs ~500+ bytes de headers por cada poll HTTP individual.

La mayoría de las aplicaciones no debería programar a mano lo que viene después — el idioma de producción es una capa de tiempo real gestionada donde el socket, los heartbeats y la reconexión son código de otra persona:

// 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 lo demás que mueve datos

Operar sockets en producción

Cuatro conceptos cargan el peso operativo. Afinidad de sesión: las conexiones tienen estado, así que los balanceadores de carga deben mantener a cada cliente anclado a su nodo. Fan-out: transmitir un mensaje a diez mil suscriptores repartidos en muchos nodos requiere un backplane de pub/sub entre servidores — el mensaje viaja de servidor a servidor antes de viajar de servidor a cliente. Backpressure: a un teléfono lento en una mala red no se le puede permitir acumular mensajes sin límite en la memoria de tu servidor; descarta, fusiona o desconecta. Vitalidad: los frames ping/pong más los heartbeats de aplicación detectan conexiones medio muertas, y los clientes se reconectan con backoff exponencial y jitter, y luego vuelven a suscribir su estado — el paso que las implementaciones ingenuas olvidan. Nada de esto es exótico; todo esto es la razón por la que “solo abrimos un socket” se convierte en una decisión de plataforma.

De mensajes a sincronización: la capa de arriba

Los WebSockets crudos mueven bytes; las aplicaciones quieren estado. El salto es la sincronización en tiempo real: en lugar de inventar a mano tipos de mensajes y contabilidad del lado del cliente, te suscribes a datos — una consulta, un documento, un canal — y la capa entrega eventos de cambio precisos, maneja la reconexión con puesta al día y aplica permisos del lado del servidor por suscriptor. Ese es el modelo de las live queries: WebSockets como transporte, un motor de consultas como cerebro. Si tu código de WebSocket está acumulando switch sobre tipos de mensajes, estás reconstruyendo esta capa a mano.

Casos de uso comunes

• Chat y mensajería — el caso canónico: ambos lados hablan, al instante.
• Presencia — quién está en línea, quién está escribiendo: mensajes diminutos, alta frecuencia, en ambos sentidos.
• Edición colaborativa — documentos y pizarras compartidas, donde posiciones de cursor y ediciones fluyen continuamente.
• Dashboards en vivo y tickers — push del servidor con números que cambian; SSE también encaja cuando es de un solo sentido.
• Multijugador y ubicación — estado de juego y marcadores de mapa en movimiento, donde la latencia es el producto.

¿Necesitas un socket? Matriz de decisión

Y el camino intermedio que la matriz esconde: los casos de solo servidor a cliente (feeds, notificaciones) encajan en SSE con menos maquinaria — la comparación completa de transportes tiene su propia entrada en el registro de este glosario.

Limitaciones y trade-offs

• El estado es el precio del push. Cada conexión abierta es memoria del servidor y una restricción de balanceo de carga; la ausencia de estado de HTTP cargaba más peso del que parecía.
• Las redes odian las conexiones de larga vida. Proxies, radios móviles y laptops cerrándose cortan sockets constantemente — la lógica de reconexión no es un caso borde, es el bucle principal.
• La seguridad se muda a la conexión. Autentica al conectar, valida cada mensaje, aplica autorización por suscripción — y siempre wss.
• El caching aquí no existe. Todo lo enviado por push se calcula y entrega por cliente; el CDN no puede ayudarte.
• La sincronización hecha a mano es una trampa. La distancia entre “abrí un socket” y “sincronización de estado correcta, con reconexión y permisos” es donde vive la ingeniería real — que es exactamente la capa que vale la pena alquilar.

WebSockets en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su capa de tiempo real es Live Query: el transporte WebSocket, los heartbeats, la reconexión y el fan-out multi-nodo corren como infraestructura gestionada (con el protocolo abierto LiveQuery por debajo), mientras tu código se suscribe a consultas y recibe eventos de cambio tipados — con ACLs aplicadas por suscriptor, para que el tiempo real nunca se salte el modelo de permisos. Las pestañas de código de arriba son toda la historia del lado del cliente.