Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — WebSocket#

⬅️ Clase 107 · 📚 Parte 8

Por qué sí Por qué no Qué se paga
Express ws se engancha al servidor que ya hay: Express ni se entera Nada más: difusión, salas y reconexión van a mano Escribir lo que las capas de encima regalan
FastAPI El decorador se parece al de una ruta y se lee igual Una tarea ocupada mientras la conexión viva Dimensionar por conexiones, no por peticiones
Spring Boot Es una pieza del framework: inyección y sesión en el apretón Su camino cómodo —STOMP— es otra capa, no el protocolo Elegir entre el protocolo y la capa, sabiendo cuál usas
Socket.IO Eventos con nombre, salas y reconexión de serie El cliente tiene que ser Socket.IO, y punto Interoperabilidad, a cambio de comodidad

🧭 Lo que este contrato no puede probar#

💡 Lo que hay que llevarse#

Lo primero es la frase que hay que decir antes de elegir esto: deja de ser HTTP. No es una pega retórica, es una lista concreta de cosas que dejan de funcionar — las herramientas de línea de órdenes, los registros de acceso por ruta, las cachés, la autenticación por cabecera en cada mensaje, los intermediarios que no lo entienden, y el verificador de esta obra. Que el contrato de esta clase no pueda abrir un WebSocket es la demostración, no un defecto del contrato.

Lo segundo es lo que sí se puede comprobar desde fuera, y merece la pena saber hacerlo: el apretón de manos. El servidor devuelve el SHA-1 de la clave del cliente concatenada con una cadena fija del RFC, en base64. Sale igual en los cuatro frameworks porque no es de ninguno, y con la clave de ejemplo del RFC la respuesta es siempre s3pPLMBiTxaQ9kYGzzhZRbK+xOo=. Veinte líneas de socket TCP y ya sabes si un servidor implementa el protocolo de verdad.

Lo tercero es la pregunta que hay que hacerse el primer día y casi nadie hace: ¿dónde va a vivir la lista de conexiones? Tres de los cuatro te la dejan a ti, y lo natural es un conjunto en memoria. Funciona perfectamente con una instancia y se rompe en silencio con dos: media sala deja de recibir la mitad de los mensajes. Eso es la clase 109, y la respuesta correcta —un canal de mensajes por fuera— hay que decidirla antes de tener cien mil líneas escritas alrededor.

Y lo cuarto, sobre las capas de encima. Socket.IO y STOMP regalan eventos con nombre, salas y reconexión, que son cosas que todo el mundo acaba escribiendo. Cobran interoperabilidad: el cliente tiene que hablar su idioma. La decisión no es de gusto: depende de quién va a conectarse. Si es siempre un navegador tuyo, la capa sale a cuenta. Si algún día va a ser un dispositivo, un servicio en otro lenguaje o alguien con un curl, no.

Fuentes#