Hay un término que se está haciendo muy famoso cuando se programa con HTTP y es real-time. El término lo emplean actualmente para referirse a obtener una respuesta rápida o incluso recibir información cuando esta está disponible pero, ¿sabes que este término no es correcto?
Has pasado del título y del resumen y quieres leer lo que tengo que contarte, así que te pido paciencia y sobre todo comprensión. Este no es una queja sino una observación hacia el poco cuidado que existe en el gremio de la computación a la hora de nombrar cosas.
Como nota a esto último, Grace Hopper intentó que muchos de sus coetáneos entre los años 1950 y 1960 dejaran emplear similitudes con el cuerpo humano cuando hablaban de computación y consiguió que se dejara de nombrar a la CPU como cerebro, pero no consiguió cambiar el término de memoria por otro que no guardase relación con el cuerpo humano.
¿Qué es real-time?
En la definición del término se dice que tiempo real es obtener una información o realizar una tarea en un tiempo oportuno siendo marcada como tiempo real blando si disponemos de un margen de tiempo en el que aún se puede realizar la tarea o se puede recibir la información o tiempo real duro si pasado el tiempo marcado esa información o tarea son desechados.
Ahora pensemos en qué se nombra como tiempo real cuando hablamos de conexiones de AJAX o WebSocket. En este tipo de comunicaciones se dice que obtenemos tiempo real cuando un evento o información generada en el servidor llega directamente al cliente sin necesidad de haberlo solicitado. Aunque, y aquí viene la nota disonante, no hay tiempo límite para obtener la información, nada se desecha.
Es un gran cambio y es lo que hace que de tiempo real pasemos a otro concepto completamente diferente: comunicación asíncrona.
¿Qué es la comunicación asíncrona?
Uno de los puntos fuertes de la arquitectura reactiva o sistemas reactivos es la comunicación asíncrona. La comunicación asíncrona es una forma de comunicación que se produce enviando la información de un punto hacia otro sin necesidad de esperar por una confirmación.
Los eventos no se producen en tiempo real sino de forma asíncrona. Estos eventos no son desechables ni requieren su llegada en un tiempo concreto sino que puede llegar segundos más tarde y tener el mismo efecto.
¿Qué daño hace llamar a WebSocket tiempo-real?
Pues en principio no mucho porque hay poca gente que programe interfaces con WebRTC, que es una interfaz para desarrollar comunicaciones que sí requieren de tiempo real como son las llamadas de audio.
Una llamada de audio requiere que el audio que se produce en un lugar llegue en un tiempo específico al otro lado y si se demora, sea desechado para que los siguientes paquetes que serán oportunos no se demoren y puedan llegar a su destino.
Pero, si WebRTC se desarrolla sobre WebSocket, ¿no es WebSocket tiempo real? Pues no. La característica de tiempo real la da precisamente el algoritmo de priorizar y desechar la información de que dispone RTC.
¿Qué importancia tiene hoy en día el tiempo-real?
¿Has visto alguna vez un videojuego? De repente, el Internet sufre un pequeño colapso y sin mover tu personaje comienzan a llegar las órdenes que diste cuando el sistema no podía procesarlas, por lo que las órdenes que envías al personaje justo en el momento que ya va fluido Internet, no se dan, el juego comienza a ser frustrante. Juega solo y no puedes hacer nada.
Eso se debe a que la información de control del personaje es oportuna. Si no se atiende en el momento que importaba, carece de sentido, debe ser desechada.
Por lo tanto, hemos visto que esto sucede así en telecomunicaciones, videojuegos en línea y sobre todo, en sistemas de misión crítica. No obstante, estos sistemas tienen aún mayor control sobre la información, pero el principio es similar.
Por lo que, si puedes, deja de decir tiempo real cuando no lo sea y di lo que sí es, es decir, comunicación asíncrona.
