React Realtime: De Sockets a Streams (Web & Native)

Hola a todos, soy Violina, desarrolladora de software en ClickMyHorse.tv, y hoy vamos a hablar sobre cómo hacer que las aplicaciones de React sean realmente en vivo, tanto en la web como en el móvil, pasando de sockets a streams. Porque los datos en tiempo real ya no son solo algo agradable de tener. Es lo que los usuarios esperan. Imagina una aplicación de chat que no se actualiza hasta que la refrescas o un precio de acciones que tiene minutos de antigüedad. Esa es una experiencia de usuario terrible.

Hoy en día, los usuarios esperan retroalimentación instantánea. Esta charla trata sobre cómo pasamos de datos obsoletos a aplicaciones de React en tiempo real tanto en la web como en React Native. Comenzaremos con WebSockets, el estándar para aplicaciones en tiempo real. Luego pasaremos a WebRTC para datos y transmisión de igual a igual. Y finalmente, echaremos un vistazo a WebTransport, el futuro construido sobre Quick y HTTP3.

React hoy en día impulsa alrededor del 45% de los frontends modernos, y ese número sigue creciendo. La adopción de React Native también está acelerándose, especialmente para equipos híbridos que quieren compartir lógica entre la web y el móvil. Así que cuando hablamos de patrones en tiempo real, no son solo para un entorno. Tienen que funcionar en ambos. Por supuesto, los desafíos se ven diferentes. En la web, los navegadores pueden ser impredecibles. Las pestañas en segundo plano, los temporizadores de aceleración y los límites de conexión pueden romper todas tus suposiciones.

En móvil, las redes caen inesperadamente. El sistema operativo puede suspender tu aplicación, y la duración de la batería se convierte en una preocupación real. Por eso es tan importante entender estos fundamentos en tiempo real. Nos dan herramientas para mantenernos conectados, sin importar la plataforma.

Ahora, antes de llegar a las cosas modernas, echemos un vistazo rápido a cómo solíamos manejar las actualizaciones en tiempo real. Comprender de dónde venimos hace claro por qué el polling tenía que desaparecer. El polling solía significar preguntar constantemente al servidor por actualizaciones, desperdiciando ancho de banda y ciclos del servidor. Las aplicaciones modernas mantienen una conexión bidireccional persistente abierta. Las actualizaciones fluyen automáticamente en tiempo real. Ahí es donde WebSockets brillan.

Las conexiones WebSocket tienen una URL específica de WebSocket. Hay dos tipos de esquemas de WebSocket. Estos son WS para conexiones no cifradas y WSS para cifradas. La comunicación WebSocket comienza con una solicitud HTTP iniciada por el cliente al servidor. La conexión WebSocket se establece a través de un handshake HTTP inicial en el cual el cliente solicita y el servidor acepta actualizar el protocolo. Con el handshake completo, se abre un canal de comunicación bidireccional persistente, permitiendo que el cliente y el servidor hablen y escuchen simultáneamente en un intercambio continuo de datos en tiempo real.

La última parte del protocolo es la terminación. La conexión WebSocket puede ser terminada por el cliente o el servidor enviando un marco de control especial para indicar la intención de cerrar la conexión. Al recibir el marco de cierre, la otra parte lo reconoce y la conexión es cerrada por ambos lados. Lo que tenemos son marcos ligeros, actualizaciones instantáneas, la columna vertebral para aplicaciones de chat, notificaciones, feeds en vivo y más.

Sin embargo, en aplicaciones del mundo real, la fiabilidad es clave. Si tu conexión se cae en móvil, necesitas una estrategia de reconexión automática con intervalos de retroceso. En React, podemos crear una conexión WebSocket en solo unas pocas líneas. Es tan simple como llamar a un solo constructor. Al llamar a WebSocket y pasar la dirección en el servidor, la conexión se intentará automáticamente para ti. Si la conexión es exitosa, entonces se devolverá un objeto WebSocket para que lo uses más tarde.

El objeto WebSocket devuelto tiene algunos eventos a los que puedes suscribirte. OnOpen se dispara cuando te has conectado exitosamente al servidor WebSocket. OnMessage se dispara cuando se recibe un mensaje del servidor WebSocket. OnClose se dispara cuando te has desconectado del servidor WebSocket. También tienes un evento no-error para lidiar con problemas con la conexión WebSocket. Aquí hay un ejemplo completo en una aplicación React. Tenemos un ticker de precios de Bitcoin usando Binance Free WebSocket API. Sin niveles de pago, sin complicaciones, solo datos de comercio en streaming directamente a tu aplicación. La función React WebSocket está envuelta en un hook useCallback y se activa a través de useEffect al montar el componente.

Esto mantiene nuestra conexión limpia, resistente y eficiente. Primero, ¿por qué useCallback? Estamos memorizando esta función para que no se recree en cada renderizado. Súper importante cuando dependencias como nuestro manejador de mensajes podrían causar renderizados innecesarios. El array de dependencias aquí es solo handleWebSocketMessage. Cuando la conexión se establece exitosamente, lo registramos para depuración, eliminamos cualquier temporizador de reconexión pendiente y ocultamos el cargador, lo cual es una luz verde de que los datos están llegando.

A continuación está nuestro onMessage handleWebSocketMessage, que contiene datos de comercio entrantes de Binance, JSON, con precio y toda otra información importante. Nuestro manejador analiza y actualiza los ticks de la interfaz de usuario en milisegundos. A continuación está el onClose. Cuando las conexiones caen por interrupciones de red, mantenimiento de Binance, o cualquier otra razón, advertimos con el código de cierre, mostramos el cargador nuevamente y programamos un reintento a través de setTimeout. Ese refStoreTimeoutId nos permite cancelarlo más tarde si nos reconectamos temprano.

¿Necesitamos retroceso exponencial aquí? Podríamos agregar eso, pero tres segundos lo mantienen simple y rápido para demostraciones. Finalmente, onError. En caso de cualquier error, los registramos y forzamos el cierre para activar onClose y reconectar. No hay conexiones colgantes. Estos manejadores mantienen tu flujo a prueba de balas. En React Native, la API se ve casi idéntica, pero la fiabilidad es más difícil. Las redes móviles caen, cambian o se ralentizan. Cómo manejar los cambios de Wi-Fi 5G móvil, pero agregar estado actualizado desde React Native para pausas de fondo de la aplicación como cerrar, WebSocket en desenfoque para ahorrar batería.

No olvides mostrar el estado de la conexión. A los usuarios les gusta saber cuándo te estás reconectando. Hasta ahora, hemos hablado sobre obtener datos hacia y desde un servidor en tiempo real. Pero, ¿y si pudiéramos evitar el servidor para el intercambio real de datos? ¿Qué pasaría si dos clientes pudieran comunicarse directamente entre sí? Ahí es donde entra WebRTC, y es un cambio de juego para muchas aplicaciones en tiempo real.

WebRTC, o comunicación en tiempo real, es fundamentalmente diferente de lo que hemos visto con WebSockets. Mientras que WebSockets mantienen una conexión persistente con un servidor central, WebRTC se trata de habilitar la comunicación directa de igual a igual entre navegadores o dispositivos. Una vez que se establece una conexión, audio, video e incluso datos arbitrarios pueden fluir directamente entre los participantes sin tocar tu servidor. Este enfoque desbloquea casos de uso como videollamadas, herramientas de colaboración en vivo y experiencias multijugador de alto rendimiento que dependen de una latencia ultra baja.

Pero podrías estar pensando, si es de igual a igual, ¿cómo encuentran dos navegadores el uno al otro en el vasto internet abierto? No pueden simplemente comenzar a hablar mágicamente. Este es el truco de WebRTC. Es de igual a igual para los datos, pero necesita un servidor central para el descubrimiento. Este proceso se llama señalización. Piénsalo como dos personas tratando de encontrarse en un estadio enorme y lleno de gente. No pueden simplemente gritar y encontrarse. Primero usan un teléfono celular, ese es nuestro servidor de señalización, para averiguar dónde están y acordar un lugar de encuentro.

Aquí está cómo se ve ese flujo en la diapositiva. Primero tenemos la fase de señalización, que es el handshake. El cliente A le dice al servidor de señalización, quiero llamar al cliente B. Este servidor, que por cierto a menudo es solo un servidor WebSocket, pasa mensajes de ida y vuelta. Intercambian candidatos de código IC completo de red y detalles de medios en una oferta y una respuesta. Luego tienen que lidiar con el mundo real. Enrutadores domésticos y firewalls de oficina. Aquí es donde entran los servidores STUN y TURN. Actúan como una guía, ayudando a los dos navegadores a encontrar un camino directo y público entre sí. Y finalmente, una vez que se encuentra ese camino, ocurre la magia. Se establece una conexión directa, completamente cifrada de igual a igual. El trabajo del servidor de señalización está hecho. Todos los datos pesados, el audio, video o estado del juego ahora fluyen directamente entre los pares, dándonos esa latencia ultra baja. Así que para resumir, los clientes usan el servidor para el handshake inicial y luego establecen un enlace directo para los datos reales.

Ahora que sabemos cómo funciona WebRTC conceptualmente, veamos cómo darle vida dentro de nuestras aplicaciones React y React Native. En la web es sorprendentemente sencillo. Los usuarios ya exponen la API de conexión RTC peer, por lo que puedes comenzar a construir conexiones de igual a igual directamente. Puedes crear flujos locales, adjuntarlos a elementos de video y manejar canales de datos sin instalar nada extra. En React Native es un poco diferente. Dado que no hay un motor de navegador bajo el capó, necesitamos un puente a las APIs nativas. Ahí es donde entra la biblioteca React Native WebRTC. Proporciona un polyfill para las mismas APIs de navegador, por lo que tu código de React y React Native puede compartir gran parte de la misma lógica. Por supuesto, el mayor desafío es la señalización. WebRTC no incluye esa parte. Aún necesitas implementar un canal de señalización separado, típicamente usando WebSockets o un backend existente para intercambiar las descripciones de sesión y candidatos IC que ayudan a los pares a encontrarse y conectarse entre sí. Una vez que la señalización está hecha, WebRTC maneja todo lo demás, desde el cifrado y transporte de medios hasta la adaptación automática de bitrate.

Entonces, en resumen, la web te ofrece WebRTC de forma nativa. React Native necesita React Native WebRTC para paridad. Ambos dependen de WebSockets o algo similar para manejar la señalización.

Ahora que sabemos cómo funciona WebRTC conceptualmente, veamos cómo darle vida dentro de nuestras aplicaciones React y React Native. Aquí hay una función mínima que configura una conexión entre pares, captura la cámara local y el micrófono, y se prepara para conectarse a otro par a través de la señalización. Comenzamos creando una nueva conexión RTC entre pares. Este es el corazón de WebRTC. Gestiona los canales de red y los flujos de medios entre pares.

A continuación, obtenemos acceso a la cámara y el micrófono del usuario usando Navigator, Media Devices, Get User Media. Una vez que ese flujo regresa, lo adjuntamos a un elemento de video local para que podamos ver nuestra propia vista previa. Luego, tomamos cada pista de ese flujo y la añadimos a la conexión. Esto le dice a WebRTC qué medios queremos enviar al otro lado. En el extremo receptor, escuchamos eventos on-track. Siempre que el par remoto nos envía audio o video, adjuntamos ese flujo entrante a otro elemento de video. Así es como obtendremos renderizado de video en tiempo real directamente en el navegador. Finalmente, creamos una oferta SDP. Esta es la forma de WebRTC de describir lo que estamos enviando y qué formatos soportamos.

Lo configuramos como nuestra descripción local y luego lo enviamos al par remoto a través de un servidor de señalización, típicamente sobre WebSockets. Una vez que el sitio remoto responde con su propio SDP, lo configuramos como nuestra descripción remota. Y así, tienes una conexión entre pares funcionando. Entonces, este pequeño fragmento captura la esencia de WebRTC en la web. Enviamos medios locales, establecemos una conexión e intercambiamos metadatos a través de la señalización.

Ahora veamos cómo se traduce esto en React Native. En un navegador, tenemos acceso a las APIs integradas de WebRTC, cosas como RTC peer connection y getUserMedia. Pero en React Native, no tenemos un entorno de ejecución de navegador. Así que necesitamos la biblioteca que une esas mismas capacidades a las APIs nativas de iOS y Android. Ahí es donde entra React Native WebRTC. Proporciona la misma superficie de API, solo que respaldada por módulos nativos. Así que el código se ve casi idéntico. Visualmente, la arquitectura es exactamente la misma que antes. Todavía tenemos el servidor de señalización conectando dos pares, pero ahora un lado podría ser un navegador y el otro una aplicación móvil, ambos usando el mismo flujo de negociación de WebRTC.

Esto significa que realmente puedes construir llamadas de video multiplataforma o herramientas colaborativas, donde tu aplicación React Native y tu aplicación React Web se comunican directamente a través de una conexión entre pares. Ese es el poder de una arquitectura en tiempo real compartida. La misma lógica, diferentes entornos de ejecución. A continuación, retrocedamos y veamos cuándo usar WebRTC versus WebSockets. Porque aunque ambos permiten la comunicación en tiempo real, resuelven problemas muy diferentes. WebSockets son tu opción para la comunicación cliente-servidor. Herramientas como chat, notificaciones, paneles en vivo o ediciones de documentos colaborativos. Son confiables, eficientes y simples de configurar.

Por otro lado, WebRTC se trata de conectividad entre pares, transmitiendo audio, video o incluso datos en bruto directamente entre dispositivos. Es la columna vertebral de las herramientas de videoconferencia, colaboración en vivo y juegos multijugador en tiempo real. En resumen, si tus datos fluyen a través de un servidor, WebSockets brillan. Si tus datos fluyen directamente entre usuarios, WebRTC es la elección correcta. Solo ten en cuenta que la configuración de WebRTC es más complicada. Necesitas manejar la señalización, servidores stern turn y el flujo de medios, pero la recompensa es una latencia ultra baja y una carga reducida en el servidor. Por supuesto, ninguno de estos es perfecto. WebSockets pueden atascarse detrás del modelo de fiabilidad de TCP, y WebRTC puede ser excesivo si solo necesitas sincronización de datos. Ahí es donde entra la próxima evolución en el transporte en tiempo real. Transporte web impulsado por el protocolo QUIC y HTTP 3.

0. Veamos cómo podría ser el futuro de la comunicación en tiempo real. Así que hemos visto WebSockets y WebRTC, los espectadores en tiempo real, pero los navegadores están avanzando hacia adelante. Con HTTP 3.0 y QUIC, obtenemos un nuevo protocolo, WebTransport. Es como el sucesor espiritual de WebSockets, pero con menor latencia, multiplexación incorporada, y mejor control de congestión. WebTransport te permite abrir múltiples flujos bidireccionales o datagramas sobre una sola conexión.

Eso significa que puedes enviar varios flujos de datos independientes como mensajes de chat, actualizaciones de presencia, y telemetría, todo sin bloquearse entre sí. Se ejecuta sobre HTTP 3.0, lo que significa mejor rendimiento sobre redes inestables y dispositivos móviles. Y porque QUIC está basado en UDP, la configuración de la conexión es más rápida, y la recuperación de pérdida de paquetes es más suave que con TCP. Piénsalo como un WebSocket 2.