Top
Programación reactiva- Primera parte – Blog Ceiba
fade
52
post-template-default,single,single-post,postid-52,single-format-standard,eltd-core-1.1.2,flow-ver-1.4,,eltd-smooth-page-transitions,ajax,eltd-blog-installed,page-template-blog-standard,eltd-header-standard,eltd-sticky-header-on-scroll-up,eltd-default-mobile-header,eltd-sticky-up-mobile-header,eltd-menu-item-first-level-bg-color,eltd-dropdown-default,eltd-dark-header
Blog Ceiba / Arquitectura  / Programación reactiva- Primera parte

Programación reactiva- Primera parte

Esta es una introducción sobre el concepto de PROGRAMACIÓN REACTIVA, el objetivo de este artículo es ilustrar los conceptos básicos de este modelo de programación que está evolucionando bastante bien para programar aplicaciones muy robustas y escalables en internet.

 

En algún momento de nuestras vidas quizás nos hemos preguntado alguna vez:

 

¿Cómo hacen las hojas de cálculo para mantener actualizados los valores de las celdas que contienen fórmulas muy complejas y dependientes del resultado de otras fórmulas?; ¿cómo hace una aplicación de alto rendimiento para escalar masivamente en internet? ó tal vez, ¿cuál es el modelo de programación detrás del éxito de NetFlix?. Pues una de las posibles respuestas sería la programación reactiva.

 

La programación reactiva es un paradigma de programación que está orientado a los flujos de datos y más específicamente a la propagación de los cambios de los datos en dicho flujo.
Es algo como esto:

 

Supongamos que tengo una expresión matemática:

 

Y = F(x) (1)

 

con F(x) muy simple o muy compleja y puede, en algunos casos, depender de otras funciones.

 

Entonces, en los modelos de programación convencional, cada vez que queramos determinar el valor de “Y” debemos evaluar la expresión “F(x)” completamente, más aún, si uno de los componentes de “F(x)” cambia, el valor de “Y” no cambiará hasta que volvamos a evaluar la expresión completamente en algún momento de nuestro algoritmo. “Y” no se da cuenta de que cambiaron sus componentes y mantendrá el resultado anterior hasta una nueva evaluación completa de “F(x)”, es más, el valor de “Y” está desincronizado con respecto a sus componentes en “F(x)”.

 

¿No sería formidable que el valor de “Y” cambiara inmediatamente cada vez que alguno o varios de los componentes de “F(x)” cambiaran y así mantener el valor de “Y” actualizado siempre?

 

Ahora, en un modelo de programación reactiva el valor “Y” siempre se va a mantener “sincronizado” con los cambios que pueda sufrir algunos componentes de la expresión “F(x)”, debido a que en programación reactiva un resultado de una operación o acción, “Y”, depende de la propagación de los cambios (eventos) de un flujo de datos, en nuestro caso “F(x)”. Es decir “Y” se suscribe a los cambios (eventos) de los componentes de “F(x)”.
Si señores, es una evolución del patrón de diseño “Observador”.
Aterricemos nuestro ejemplo y supongamos que deseamos mantener actualizado el salario de una persona, entonces nuestro flujo de datos o “F(x)” será algo así como:

 

F(x) = f(HorasOrdinarias) + f(HorasExtras) + f(Comisiones) – f(Descuentos)

 

Entonces F(x) se suscribe a los cambios de f(HorasOrdinarias), f(HorasExtras), f(Comisiones) y f(Descuentos), así cada que cambie uno de los componentes del flujo de datos F(x) reaccionará a este cambio y procederá a actualizar el valor del salario.

 

Observemos uno de los componentes de F(x), por ejemplo f(HorasOrdinarias): Este componente a su vez es función del número de horas trabajadas y función del valor de la hora ordinaria; entonces f(HorasOrdinarias) también se puede suscribir a los cambios presentados en el número de horas ordinarias y a los cambios de valor de la hora ordinaria.

 

Como lo podemos observar en el ejemplo, en programación reactiva las definiciones de flujos de datos pueden ser recursivas y como tal las debemos tratar.

 

Así un suscriptor de un componente puede publicar a su vez cambios a otros componentes que lo están observando.
Pero, ¿cómo se puede lograr todo esto?

 

Cada componente debe ser un componente observable – según el patrón de diseño observador – al ser observable debe tener una lista de componentes que lo observan o que están suscritos a sus cambios, observadores.

 

El observable cada que vez que determina que ha ocurrido algún cambio en su interior notifica de manera asincrónica a sus observadores los cuales reaccionarán a este evento, realizarán sus correspondientes acciones y notificarán a otros componentes si es el caso.
Al poder ser también cada componente observable un observador de otros componentes, se va configurando un grafo de incidencias el cual es evaluado constantemente para determinar referencias circulares en la evaluación de los flujos de datos.

 

El objetivo de la programación reactiva es que podamos, de una manera muy fácil en nuestro lenguaje de preferencia, expresar flujos de datos ya sean estáticos o dinámicos que reaccionen a cambios en ciertas condiciones y propaguen estos cambios a todos los elementos nodos del grafo; es algo así como una programación “orientada a los eventos”.

 

Otro ejemplo ilustrativo:

 

Imaginémonos un sistema complejo de inventarios empresarial. Un inventario es una función de entradas y salidas; las entradas pueden ser compras, traslados, devoluciones y cada uno de estos componentes pueden ser módulos a su vez de una aplicación empresarial; las salidas de un inventario pueden ser también: Ventas POS, traslados, devoluciones a proveedores, ventas online, etc. y estos también pueden ser módulos o aplicaciones empresariales.

 

Según nuestro ejemplo el inventario debe reaccionar a sus entradas y salidas registrando la información en su propia base de datos.
Pero ¿qué pasaría si el sistema de ventas POS fuera y actualizara el inventario sincrónicamente cada vez que se realice una venta?, ¿cuánto sería el tiempo que tardaría en guardarse la transacción?, aún peor ¿cuánto tiempo tiene que esperar un cliente en la caja (punto de venta) o en internet para que su compra sea efectiva?, ¿y si además de actualizar el inventario, el sistema de ventas debe actualizar el sistema de cartera si fue una venta a crédito?, ¿y si el sistema de inventario debe notificar a los proveedores la falta de un producto?
Una solución coloquial sería realizar procesos nocturnos de actualización del inventario y la cartera con la información de las ventas y luego el sistema de pedidos debe sincronizarse con los movimientos del inventario para realizar los pedidos, y la pregunta del millón ¿puede una solución así escalar en internet?

 

Entonces, ¿para qué hacerlo difícil si se puede más fácil?

 

Imagínense al sistema de ventas publicando eventos en un servidor y las aplicaciones de cartera e inventario reaccionando a estos eventos de manera asincrónica, no tendríamos retardos en las transacciones de ventas, mantendríamos el inventario actualizado y la cartera también con información a la mano en tiempo real y el inventario publicando eventos para el sistema de pedidos y éste reaccionando de la misma manera.
¿Se imaginan cómo puede escalar una solución diseñada y programada con este paradigma a millones de clientes en internet, cientos de miles de productos y miles de proveedores?

 

Para estos problemas está diseñada la programación reactiva. La programación reactiva al ser un modelo de programación es independiente de la tecnología, por eso encontraremos implementaciones de programación reactiva en JAVA, más concretamente SCALA, y también para la plataforma .NET llamada RX Framework o un lenguaje un poco más especializado como F#.

 

En próximos días veremos un poco de estas implementaciones en las diferentes plataformas.

 

Bibliografía

http://www.introtorx.com/Content/v1.0.10621.0/01_WhyRx.html
http://tabletomovil.com/7-razones-por-las-que-necesita-para-aprender-programacion-reactiva-ahora
http://msdn.microsoft.com/library/vstudio/dd492627(VS.110).aspx
http://programandonet.com/web/rx-i-que-son-las-reactive-extensions/
http://en.wikipedia.org/wiki/Reactive_programming

Jorge Moreno

Escrito por: Jorge Moreno

Me gusta investigar sobre cómo utilizar los nuevos conceptos tecnológicos en la solución de problemas de negocio, aficionado al IoT y los BlockChain.

No Comments

Comentarios