Introducción
Socket.IO es una biblioteca construida sobre el protocolo WebSocket que añade funciones amigables para el desarrollador que no están disponibles en WebSockets sin procesar. Al construir funcionalidades en tiempo real como aplicaciones de chat, editores colaborativos o paneles en vivo, a menudo necesitas agrupar clientes lógicamente, aislar canales de comunicación y manejar caídas de conexión con elegancia. Socket.IO proporciona rooms, namespaces, reconexión automática y fallback de transporte listos para usar, por lo que no tienes que ingeniártelas desde cero.
Esta lección recorre cada una de estas cuatro funciones con código concreto. Al final sabrás cómo segmentar tu servidor en namespaces, agrupar dinámicamente sockets en rooms, permitir que los clientes se reconecten automáticamente y depender de HTTP long-polling como red de seguridad cuando los WebSockets están bloqueados.
Namespaces
Un namespace es un canal de comunicación independiente que comparte la misma conexión TCP subyacente. El namespace por defecto es `/`, pero puedes crear personalizados para separar lógicamente las responsabilidades — por ejemplo, un chat público frente a un panel de administración.
En el servidor:
En el cliente:
Todo lo enviado a través del namespace `/admin` permanece aislado del namespace `/` por defecto, aunque ambos se ejecutan en el mismo servidor y puerto.
Rooms
Las rooms son subcanales dentro de un namespace. Un socket puede unirse o salir de una room en cualquier momento, y el servidor puede hacer broadcast a cada socket en una room con una sola llamada. Este es el patrón que quieres para mensajería por conversación en una app de chat o estado por sala de juego en un juego multijugador.
`socket.join(roomId)` añade el socket a un conjunto en memoria mantenido por Socket.IO. Luego, `io.to(roomId).emit(...)` entrega el payload a cada miembro de esa room. El socket que se une no recibe los mensajes enviados con `socket.to(...)` — usa esto cuando quieras notificar a "todos los demás" en la room.
Auto-Reconexión y Fallback de Transporte
Los WebSockets sin procesar dejan de funcionar permanentemente en el momento en que se cae la red. El cliente de Socket.IO maneja la reconexión automáticamente. Puedes configurar la estrategia de reintentos e informar al usuario lo que está ocurriendo mediante eventos.
El fallback de transporte es la otra mitad de la resiliencia. Socket.IO siempre intenta primero WebSocket porque es la opción de menor latencia, pero si el handshake falla — firewalls corporativos, proxies antiguos, redes restrictivas — recurre silenciosamente a HTTP long-polling. El código de la aplicación no cambia; tus llamadas `emit` y `on` funcionan de forma idéntica sobre cualquier transporte.
Errores Comunes y Resumen
Dos errores aparecen con frecuencia. Primero, no guardes la membresía de la room en tu propia variable — siempre confía en `socket.rooms` devuelto por Socket.IO, porque la biblioteca gestiona internamente las entradas y salidas y tu caché se desincronizará. Segundo, recuerda que `socket.to(roomId)` excluye al emisor mientras que `io.to(roomId)` lo incluye, así que elige el adecuado según tu intención de broadcast.
Para resumir: los namespaces dividen tu servidor en canales aislados, las rooms agrupan sockets dentro de un namespace para broadcasts dirigidos, la auto-reconexión se recupera de caídas de red sin cambios de código, y el fallback de transporte te mantiene en línea incluso cuando los WebSockets están bloqueados. Juntas, estas funciones eliminan el código repetitivo que de otro modo tendrías que escribir sobre WebSockets sin procesar.
Punto de control de la lección
Repasa lo aprendido y recibe comentarios sobre tu trabajo.