Programación Reactiva

Actores

Flujo de datos: Son datos que se van modificando cada cierto tiempo, y que puede tener interés observar en tiempo real. A diferencia de los procesos por lotes, donde los datos se recopilan y procesan en bloques, el data streaming permite la ingestión y procesamiento continuo de datos a medida que estos se generan.

Observable: Un componente que puede ser observado, y que se encargará de informar cuando ese flujo de datos se modifique.

Observador: Es el elemento que observa esas modificaciones. Cuando el dato se modifica, se notifica al componente que lo está utilizando. Normalmente este observer necesita suscribirse cuando quiere empezar a recibir datos, y desuscribirse cuando ya no le interesan más esos datos.

Dispatchers: En cada framework de programación reactiva se llaman de una forma distinta, pero básicamente son un conjunto de hilos donde se van a ejecutar las operaciones, y unas reglas que optimizan su uso para ser lo más eficientes posibles.

Operadores: Son funciones que se aplican a streams de datos haciendo uso de la programación funcional. Implementan soluciones a problemas comunes en el procesamiento de streams como agregar, filtrar, mapear. Existen montones de operadores que nos permiten modificar y combinar flujos de datos, y conocerlos todos es muy complicado. Dependen de las librerías.

Manejo de flujos de datos

Basado en datos que fluyen continuamente, los sistemas reactivos reaccionan a los datos ejecutando una serie de eventos.

Patrón de Diseño Observer

La programación reactiva sigue el patrón de diseño Observer; cuando hay un cambio de estado en un objeto, los otros objetos son notificados y actualizados acorde. Por lo tanto, en lugar de sondear eventos para los cambios, los eventos se realizan de forma asíncrona para que los observadores puedan procesarlos.

Uso eficiente de recursos

Utilizando E/S asíncrona, la idea es simple: disminuir el uso ineficiente de recursos usando recursos que de lo contrario estarían inactivos, ya que permanecen a la espera de actividad de E/S.

Liberación del cliente

Los nuevos datos se notifican a los clientes en vez de tener que solicitarlos, debido a que la E/S asíncrona invierte el diseño normal del procesamiento de E/S. Este enfoque libera al cliente para hacer otras cosas mientras espera nuevas notificaciones.

Demasiadas notificaciones

Existe el riesgo de que demasiadas notificaciones desborden al cliente.

Rechazar el trabajo que no se puede manejar

Un aspecto fundamental de control de flujo en sistemas distribuidos es que el cliente debe ser capaz de rechazar el trabajo que no puede manejar. En la programación reactiva, la capacidad del cliente para señalizar cuánto trabajo puede manejar se llama contrapresión.

En este patrón, tenemos un objeto Observable al que podemos suscribirnos, y cada vez que haya un cambio en su valor seremos informados. A esto se le conoce como Publicador-Suscriptor.

Analogía del patrón observador de la vida cotidiana: suscripción al boletín de un portal técnico

Finalidad

El patrón Observer trabaja con dos tipos de actores: por un lado, el sujeto, es decir, el objeto cuyo estado quiere vigilarse a largo plazo. Por otro lado, están los objetos observadores, que han de ser informados de cualquier cambio en el sujeto. Sin el patrón Observer, los objetos observadores tendrían que solicitar al sujeto regularmente que les enviase actualizaciones acerca de su estado (status updates). Cada una de estas solicitudes conllevaría tiempo de computación y requeriría, además, ciertos recursos de hardware.

Funcionamiento y estructura

1. El Notificador envía eventos de interés a otros objetos. Esos eventos ocurren cuando el notificador cambia su estado o ejecuta algunos comportamientos. Los notificadores contienen una infraestructura de suscripción que permite a nuevos y antiguos suscriptores abandonar la lista.
2. Cuando sucede un nuevo evento, el notificador recorre la lista de suscripción e invoca el método de notificación declarado en la interfaz suscriptora en cada objeto suscriptor.
3. La interfaz Suscriptora declara la interfaz de notificación. En la mayoría de los casos, consiste en un único método actualizar. El método puede tener varios parámetros que permitan al notificador pasar algunos detalles del evento junto a la actualización.
4. Los Suscriptores Concretos realizan algunas acciones en respuesta a las notificaciones emitidas por el notificador. Todas estas clases deben implementar la misma interfaz de forma que el notificador no esté acoplado a clases concretas.
5. Normalmente, los suscriptores necesitan cierta información contextual para manejar correctamente la actualización. Por este motivo, a menudo los notificadores pasan cierta información de contexto como argumentos del método de notificación. El notificador puede pasarse a sí mismo como argumento, dejando que los suscriptores extraigan la información necesaria directamente.
6. El Cliente crea objetos tipo notificador y suscriptor por separado y después registra a los suscriptores para las actualizaciones del notificador.

Uso eficiente de recursos

En la programación asíncrona clásica, un hilo que se ejecuta pasa la mayor parte de su tiempo esperando. El hilo que se ejecuta envía una petición, por ejemplo, a la base de datos, luego espera durante un periodo de tiempo la respuesta con los datos, cuando finalmente obtiene una respuesta, continúa trabajando y al finalizar vuelve a estar disponible para otra ejecución. Lo que hace que este recurso se esté usando de forma ineficiente.

En la programación reactiva cada hilo se centra en enviar la solicitud, y luego vuelve a estar disponible para otra ejecución. Cuando la respuesta llega, este mismo hilo, u otro, puede recoger y procesar la respuesta. En pocas palabras: trata de asegurarse de que todos los hilos estén siempre trabajando en algo, y no esperando.

La utilización eficiente de los recursos deriva en gastar menos dinero en servidores y centros de datos. La promesa de la programación reactiva es que se puede hacer más con menos. Específicamente se puede procesar cargas de trabajo más altas con menos hilos.

Mantenibilidad

La combinación de flujos con potentes operadores resuelve problemas complejos de una manera muy declarativa. El código parecerá conciso y directo; en lugar de ramificaciones verbales y lógica imperativa, se tienen combinaciones de operadores que facilitan hacerse una imagen mental del funcionamiento. Lo cuál, hace más sencillo que cualquier persona diferente al desarrollador original, pueda modificar o mejorar algún aspecto en el código más rápido.

Escalabilidad

Usando programación reactiva se obtiene una implementación débilmente acoplada, que tiende a aislar los fallos y que tiene la capacidad de escalar horizontalmente y de forma rápida, permitiendo el manejo de grandes cantidades de eventos, que pueden ser millones o billones de eventos, muy útil para “Big Data”.

Facilidad en el manejo del backpressure

Se pueden dar situaciones donde un Notificador genere más elementos de los que un Suscriptor puede consumir. Lo cual genera que el proceso de convertir esa entrada en salida se resista de alguna manera. En la mayoría de los casos esa resistencia es la velocidad de cálculo.

Para manejar estas situaciones en la programación reactiva se han establecido los siguientes mecanismos: Los suscriptores pueden indicar el número de datos que quieren o pueden procesar, de manera que el notificador nunca les enviará más de n cantidad de elementos. Los notificadores pueden aplicar diferentes operaciones como buffers o descartar algunos datos, para evitar saturar a los suscriptores lentos.

Backpressure es una solución que implementa el modelo Pull o el patrón de diseño Iterador. Así, hoy día el patrón la programación reactiva implementa dos patrones de diseño : Observer e Iterador

Implementación

Lograr los comportamientos que se logran de forma fácil en el paradigma reactivo, resultan muy complicados y con el uso de artefactos complicados en otros paradigmas de programación.

Esta facilidad de implementación se puede evidenciar por la relativa rapida acogida de los componentes reactivos en tecnologías de Front-End, interfaces de usuario y hasta gestores de carga y replicacion en entornos de Cloud.

Mayor costo en memoria

Este paradigma es más costoso en memoria, porque requiere mayor espacio en memoria para almacenar los flujos de datos (ya que se basa en flujos a lo largo del tiempo).

Curva de aprendizaje

La curva de aprendizaje es grande para dominar la programación reactiva. No sólo se está expuesto a un ecosistema completamente nuevo con nuevas APIs, sino que también se necesita tiempo para procesar este paradigma diferente de programación con streams, que puede ser bastante diferente de un estilo de código de escritura tradicional (por ejemplo, en comparación con la programación imperativa). También puede que se necesite aprender de nuevas herramientas para las pruebas unitarias y dominar conceptos adicionales como los diagramas de mármol, que ayudan a modelar adecuadamente los flujos de datos. Además, hay una falta de recursos buenos y sencillos para aprender.

Depurar no es más fácil

Del mismo modo que en la programación clásica donde nos podemos encontrar con un espagueti de funciones. En la programación reactiva también se puede encontrar un espagueti de flujos y no saber qué camino tomar. Con las funciones simples suele ser más sencillo hacer una depuración del código, dado que se componen secuencialmente. Con los flujos, puede que no sea tan sencillo porque no existe tal cosa como un flujo que invoca a otro flujo. En su lugar, se tiene un flujo que se conecta con otros flujos de maneras mixtas dependiendo de los operadores que los unen.

Acumulación de delay

Los sistemas reactivos pueden acumular fácilmente retrasos debido a un número excesivo de procesos vinculados al flujo.

Los orígenes de la programación reactiva se remontan, probablemente, a la década de 1970, pero esta empezó a resonar en la década del 2010, al mismo tiempo que comenzó el auge de los microservicios y los procesadores multinúcleo.

Desde entonces, dicho paradigma ha evolucionado de manera significativa y, por este motivo, las librerías que lo implementan pueden clasificarse en generaciones de acuerdo a su grado de madurez, según la categorización propuesta por el autor David Karnok en el año 2016, la cual se describe a continuación:

Orígenes

En las primeras aplicaciones de GUI, la interfaz se actualizaba solo después de una acción del usuario, como hacer clic en un botón. El núcleo de la aplicación era un bucle de eventos que esperaba sincrónicamente la entrada del usuario, lo que hacía que la aplicación se colgara si no había interacción.

La solución es desacoplar el manejo de eventos de la actualización de la GUI, utilizando una cola de eventos y un procesamiento paralelo. En este patrón productor-consumidor, un hilo maneja la entrada del usuario y coloca eventos en la cola, mientras otro hilo consume estos eventos y actualiza la GUI.

Generación 0

Consiste, principalmente, de la API java.util.Observable y de otras API basadas en callbacks, tal como addXXXListener en Swing, AWT y Android.

Los inconvenientes que presentaban las herramientas de esta generación eran las deficiencias de composición y el hecho de que, por sí mismas, resultaban bastante limitadas.

Primera generación

Una vez que Erik Meijer y el equipo de Microsoft reconocieron y abordaron las deficiencias, nació la primera generación de bibliotecas de programación reactiva: Rx.NET alrededor de 2010, Reactive4Java en 2011 y las primeras versiones de RxJava en 2013.

Algunos de los inconvenientes encontrados consistieron en que, al implementar las interfaces IObservable/IObserver no se podían cancelar las secuencias en ejecución usando el operador take(), además del problema de la falta de backpressure.

Segunda generación

El equipo de RxJava identificó estas deficiencias y se diseñó una nueva arquitectura. En esta se introdujo: la clase Subscriber, la cual puede decir si está interesada en más eventos o no; la interfaz Producer, para señalar la cantidad de elementos que un Subscriber puede procesar a la vez, y el método lift(), que permite una transformación funcional entre Subscribers.

No obstante, esta solución era un poco torpe y limitaba algunas optimizaciones, además de que era incompatible con los puntos de vista de otras bibliotecas reactivas que comenzarían a surgir más adelante.

Tercera generación

Ingenieros de varias compañías se juntaron y crearon la especificación Reactive Streams. Algunos ejemplos de librerías que pertenecen a esta generación son RxJava 2.x, Project Reactor y Akka-Streams.

Cuarta generación

Algunas de estas librerías se reimplementaron, lo cual condujo al establecimiento de la librería reactive-streams-commons, a la construcción de ciertos operadores fundacionales y al diseño de componentes de optimización que pasaron a recibir el nombre de operator-fusion. Comparada con la generación anterior, aunque lucen similares en el exterior, en el interior poseen cambios significativos que permitieron una reducción aún mayor de los gastos generales.

Adicionalmente, este autor especula que, de la quinta generación en adelante, la arquitectura de Reactive-Streams requeriría ciertas extensiones para soportar operaciones reactivas de entrada y salida en la forma de secuencias bidireccionales, entre otros cambios que, en ese punto, estaban abiertos a discusión.

La programación reactiva, al tratarse de un paradigma emergente que está en constante actualización, suele confundirse con otros conceptos que también llevan la partícula "reactive" en su nombre. Este término es muy amplio y, aunque algunas personas pueden creer que las extensiones reactivas, los streams reactivos, los sistemas reactivos, y la programación funcional reactiva (entre otras muchas) sean lo mismo, la verdad es que existen diferencias importantes a considerar en todas ellas.

Programación Funcional Reactiva (FRP)

Es un paradigma de programación que combina los principios de la programación funcional con el manejo de datos que cambian a lo largo del tiempo de manera continua. En lugar de trabajar con valores discretos emitidos a lo largo del tiempo, como en la programación reactiva tradicional, la FRP se enfoca en representar y manipular valores que pueden variar continuamente. Este enfoque permite describir comportamientos dinámicos y sistemas interactivos de forma declarativa, facilitando el desarrollo de aplicaciones como animaciones, simulaciones y gráficos interactivos.

Fue definida en 1997 por Conal Elliott y Paul Hudak. De acuerdo con una presentación que Elliott dio en el año 2015, titulada "The essence and origins of FRP", el término había sido empleado incorrectamente para describir sistemas como Elm, Bacon y extensiones reactivas. La diferencia principal entre la FRP y la programación reactiva es que la primera opera en valores que cambian continuamente a través del tiempo, mientras que la segunda opera en valores discretos que se emiten a través del tiempo. La conferencia puede verse a continuación:

Extensiones y Streams Reactivos

Las extensiones reactivas, mejor conocidas como "ReactiveX" son un conjunto de herramientas que implementan el paradigma de la programación reactiva (estas se cubrirán a detalle más adelante).

Sin embargo, debido a que estas contienen una gran variedad de librerías y a la falta de interoperabilidad entre ellas, surgieron los Reactive Streams. Esta fue una iniciativa creada para proveer un estándar para las extensiones reactivas y que lidiara con el procesamiento de flujo (stream) asincrónico con contrapresión sin bloqueo (non-blocking backpressure); es decir, se buscó unificar las librerías ya existentes.

Operadores sobre Streams reactivos

Operadores de creación

of: Crea un stream a partir de una lista de elementos.

from: Convierte varios tipos de datos (arrays, promesas, iterables) en streams.

interval: Emite números secuenciales a intervalos de tiempo específicos.

timer: Emite un valor después de un tiempo determinado.

Operadores de join

merge: Combina múltiples streams emitiendo todos los valores a medida que ocurren.

concat: Emite todos los valores de un stream y luego continúa con el siguiente.

combineLatest: Combina múltiples streams emitiendo el último valor de cada uno cada vez que uno de los streams emite.

zip: Combina valores de múltiples streams en forma de tuplas, emitiendo cada vez que cada stream ha emitido un valor.

Operadores de transformación

map: Aplica una función a cada valor emitido por el stream.

scan: Acumula valores emitidos utilizando una función acumuladora, similar a reduce en arreglos.

buffer: Agrupa los valores emitidos en arrays.

Operadores de filtrado

filter: Emite solo los valores que cumplen con una condición específica.

debounceTime: Emite un valor solo si ha pasado una cierta cantidad de tiempo desde la última emisión.

distinctUntilChanged: Emite valores solo si son diferentes del valor anterior.

Operadores de multicasting

share: Convierte un stream en un stream multicast compartido entre suscriptores.

publish: Convierte un stream en un connectable observable que puede ser controlado cuándo empezar a emitir.

refCount: Convierte un connectable observable en un observable regular que se suscribe y se desuscribe automáticamente basado en la cantidad de suscriptores.

Sistemas reactivos

Los sistemas reactivos son un conjunto de principios de diseño arquitectónico para construir sistemas modernos que estén bien preparados para satisfacer las crecientes demandas que enfrentan las aplicaciones hoy en día. Sus especificaciones se pueden encontrar en línea bajo el nombre de "Manifiesto Reactivo", tal como sigue a continuación:

Esta es uno de los conceptos que suele causar más confusiones, debido al hecho de que usar programación reactiva no necesariamente conduce a la formación de sistemas reactivos. Aunque el paradigma sí es útil para satisfacer ciertos requerimientos enunciados en el manifiesto, hace falta considerar algunos puntos:

De acuerdo al white paper "Reactive Programming versus Reactive Systems", escrito por Jonas Bonér y Viktor Clang, la programación reactiva es, generalmente, dirigida por eventos, mientras que los sistemas reactivos son dirigidos por mensajes. La principal diferencia entre ambos consiste en que los mensajes son inherentemente dirigidos (siempre tienen un destino), mientras que los eventos no: estos son tan solo señales emitidas por un componente al alcanzar cierto estado.

En un sistema dirigido por mensajes, los receptores esperan por la llegada de estos y reaccionan a ellos, de lo contrario permanecen inactivos. Por otra parte, en un sistema dirigido por eventos, los detectores de notificaciones están anclados a las fuentes de dichos eventos, de tal forma que son invocados cuando el evento es emitido. En síntesis, un sistema dirigido por mensajes se centra en los destinatarios, mientras que uno dirigido por eventos se enfoca en los emisores.

De este modo, el uso exclusivo de programación reactiva puede hacer que la resiliencia sea más difícil de lograr, pues las callbacks suelen ser anónimas y, por ende, no direccionables. Es decir que, si falla una de las cadenas del flujo de datos, entonces se debe reiniciar la cadena y el cliente debe ser notificado (algo que no ocurre en un sistema dirigido por mensajes, que tendría la capacidad de autorrecuperarse sin involucrar al cliente). Sin embargo, si se integra este paradigma con una arquitectura reactiva, este termina siendo de gran utilidad a la hora de construir sistemas reactivos.

ReactiveX

Es un conjunto de herramientas que permiten que los programación imperativos operen en secuencias de datos independientemente de si los datos son síncronos o asincrónicos. Proporciona un conjunto de operadores de secuencia que operan en cada elemento de la secuencia. Es una implementación de programación reactiva y proporciona un modelo para que las herramientas se implementen en múltiples programación.

ReactiveX es una combinación de las mejores ideas del patrón Observer, el patrón Iterator y la programación funcional Reactiva.

Lenguajes con librería ReactiveX

Los siguientes lenguajes poseen una librería basada en ReactiveX que les permite pertenecer al paradigma de la Programación reactiva

• Java: RxJava
• JavaScript: RxJS
• C#: Rx.NET
• C#(Unity): UniRx
• Scala: RxScala
• Clojure: RxClojure
• C++: RxCpp
• Lua: RxLua
• Ruby: Rx.rb
• Python: RxPY
• Go: RxGo
• Groovy: RxGroovy
• JRuby: RxJRuby
• Kotlin: RxKotlin
• Swift: RxSwift
• PHP: RxPHP
• Elixir: reaxive
• Dart: RxDart

ReactiveX para plataformas y frameworks

• Netty: RxNetty
• Android: RxAndroid
• Cocoa: RxCocoa
• ROS: RxROS

Spring 5 incluye Spring WebFlux, que proporciona soporte de programación reactiva para aplicaciones web.

Spring WebFlux permitirá construir un servicio REST no bloqueante, de tal forma que se puedan hacer varias peticiones simultáneas y estas se procesen en paralelo.

Svelte presenta un enfoque nuevo para crear interfaces de usuario. Mientras los frameworks tradicionales como React y Vue hacen la mayor parte de su trabajo en el navegador, Svelte cambia ese trabajo a un paso de compilación que ocurre cuando se construye la aplicación.

Se podría decir que Svelte es un compilador que toma el código y genera JavaScript nativo que interactúa con el DOM directamente sin necesidad de un intermediario.