Bit - loader

Introducción a la Programación Reactiva: Rx


Netmind - Introducción a la Programación Reactiva: Rx    Artículo | Programación Reactiva
Ricardo Ahumada | 02/03/18

En este artículo quiero introducir un tema que lleva cierto tiempo en la cresta de la ola: la Programación Reactiva.

Vamos a intentar dar luz sobre su naturaleza, aclarar conceptos y su necesidad.

Asimismo continuaremos en siguientes artículos con los contextos o casos prácticos en los que es interesante usarla y con implementaciones de ejemplos específicos, tanto de Javascript, como de Java.

 

Qué es a la programación reactiva: Rx

La Programación reactiva o Rx, es un estilo de microarquitectura y paradigma que implica el enrutamiento inteligente y el consumo de eventos, todos combinados, para cambiar el comportamiento de una aplicación. En otras palabras:

“La programación reactiva es programación con flujos de datos asíncronos”

De cierto modo, esto no es nada nuevo. Los buses de eventos o los eventos típicos, como los clics, son en realidad una secuencia de eventos asincrónicos, que se pueden observar y así producir en consecuencia algunos efectos secundarios.

La Reactividad es esa idea con esteroides. Se pueden crear flujos de datos (streams) de cualquier cosa, no solo de eventos. En realidad, los streams son baratos y omnipresentes, cualquier cosa puede ser un stream: variables, entradas de usuario, propiedades, cachés, estructuras de datos, etc.

Por ejemplo, si se visualiza un feed de Twitter es un flujo de datos de la misma manera que los eventos de clic; se puedes escuchar esa transmisión y reaccionar en consecuencia.

Los orígenes de la Programación Reactiva probablemente se remonten a la década de 1970 o incluso antes, por lo que no hay nada nuevo acerca de la idea, pero ahora están resonando en la empresa moderna.

Esta resonancia ha llegado (no accidentalmente) al mismo tiempo que el auge de los microservicios y la ubicuidad de los procesadores multi-core.

Estos cambios están sucediendo porque los requisitos de las aplicaciones han cambiado drásticamente en los últimos años. Hace solo unos años, una aplicación grande tenía decenas de servidores, segundos de tiempo de respuesta, horas de mantenimiento sin conexión y gigabytes de datos.

Hoy las aplicaciones se implementan en todo, desde dispositivos móviles hasta clusters basados en la nube que ejecutan miles de procesadores multi-core.

Los usuarios esperan tiempos de respuesta de milisegundos y un tiempo de actividad del 100%. Los datos se miden en Petabytes. Las arquitecturas de software de ayer simplemente no satisfacen las demandas de hoy.

 

El Manifiesto Reactivo

Publicado en 2014, su objetivo es condensar el conocimiento que acumulamos como industria sobre cómo diseñar aplicaciones altamente escalables y confiables en un conjunto de características de arquitectura requeridas, y definir un vocabulario común para permitir la comunicación entre todos los participantes en ese proceso: desarrolladores, arquitectos, líderes de proyectos, gestión de ingeniería, CTOs.
Propone que los sistemas construidos como sistemas reactivos son más flexibles, ligeramente acoplados (loosely-coupled), y escalables. Esto los hace más fáciles de desarrollar y susceptibles de cambiar. Son significativamente más tolerantes con los fallos y, cuando estos se producen, lo satisfacen con elegancia en lugar de desastre. Los sistemas reactivos son altamente receptivos y brindan a los usuarios un feedback interactivo efectivo.
Por tanto propone construir sistemas Responsivos, Resilentes, Elásticos y Guiados por mensajes.

Introducción a la Programación Reactiva: Rx 0

¿Por qué necesitamos trabajar de manera asíncrona?

La respuesta simple es que queremos mejorar la experiencia del usuario. Queremos hacer que nuestra aplicación sea más responsiva, ofrecer una experiencia fluida a nuestros usuarios sin congelar su hilo principal, ralentizándolos, no queremos ofrecer aplicaciones con rendimiento pobre.
Para mantener el hilo principal libre necesitamos hacer un montón de trabajo pesado y lento en segundo plano. También queremos realizar trabajos pesados y cálculos complejos en nuestros servidores, ya que los dispositivos móviles no son tan potentes como para realizar trabajos pesados: no queremos capturar el dispositivo del usuario. Por tanto necesitamos trabajo asincrónico para las operaciones de red.

 

Componentes de una librería Reactiva

De manera simple, en la programación Rx, los flujos de datos emitidos por un componente y la estructura subyacente proporcionada por las librerías Rx propagarán esos cambios a otro componente que esté registrado para recibir esos cambios de datos.

Veamos qué necesitamos de una librería que manejara todo el proceso asíncrono:

 

Ejecución: si comenzamos la ejecución de un montón de trabajo en un nuevo hilo, deberíamos poder controlarlo. Si se va a realizar alguna tarea en segundo plano, reunir la información y prepararla. Tan pronto como esté lista, se puede iniciar la tarea de background.

 

Fácil administración de subprocesos: en los procesos asincrónicos, la administración de subprocesos es clave. A menudo necesitamos actualizar la UI en el hilo principal desde el hilo de background, en mitad de la tarea o al final de la misma. Para eso, necesitamos pasar nuestro trabajo de un hilo (hilo de background) a otro hilo (hilo principal). Por lo tanto, debería poder cambiar el hilo fácilmente y pasar el trabajo a otro hilo cuando sea necesario.

 

Fácilmente combinable: Idealmente, sería genial si pudiéramos crear un proceso asincrónico y cuando lanzamos el hilo de background, simplemente este hace su trabajo sin depender de ningún otro hilo (especialmente del hilo de Interface de usuario) y permanece independiente hasta que termina su trabajo. Pero en el mundo real, tenemos que actualizar la interfaz de usuario, realizar cambios en la base de datos y muchas cosas más que hacen que los hilos sean interdependientes. Por tanto, la librería asincrónica debe ser fácilmente combinable y dejar poco espacio para el error.

 

Mínimo los efectos secundarios: al trabajar con varios hilos, un hilo debe experimentar los mínimos efectos secundarios del otro hilo. Eso hace que el código sea fácil de leer y comprensible para un miembro nuevo en el equipo y; también hace que un error sea rastreable fácilmente.

 

Rx se compone de tres puntos clave.

RX = OBSERVABLE + OBSERVER + SCHEDULERS

 

Observable: Los Observables son las secuencias de datos. Observable empaqueta los datos que se pueden pasar de un hilo a otro. Básicamente emiten los datos periódicamente o solo una vez en su ciclo de vida en función de sus configuraciones. Existen varios operadores que pueden ayudar al observador a emitir algunos datos específicos basados ​​en ciertos eventos (los analizaremos en próximas partes). Por ahora, puedes pensar en los observables como proveedores. Procesan y suministran los datos a otros componentes.

 

Observadores: los observadores consumen la secuencia de datos emitida por el observable. Los observadores se suscriben al observable utilizando el método subscribeOn() para recibir los datos emitidos por el observable. Cada vez que el observable emite los datos, todo observador registrado recibe los datos en la devolución de llamada onNext(). Aquí pueden realizar varias operaciones, como analizar la respuesta JSON o actualizar la interfaz de usuario. Si se produce un error de observable, el observador lo recibirá en onError().

 

Introducción a la Programación Reactiva: Rx 1

 

Schedulers: Rx es se usa en programación asincrónica y, por tanto, necesitamos un administrador de subprocesos. Allí es donde los schedulers entran en escena. Son el componente que le indican a los observables y observadores, en qué hilo deben ejecutarse. Puede usar el método observeOn()  para indicar a los observadores, qué hilo debe observar. Además, puede usar scheduleOn() para indicar al observable en qué hilo se debe ejecutar.

 

Pasos para usar Rx en nuestras aplicaciones:

El siguiente diagrama presenta un ejemplo del conjunto del sistema Observanle-Scheduler-Observer:

 

Introducción a la Programación Reactiva: Rx 2

 

Paso-1 Crear observable que emite los datos

Observable<String> database = Observable //Observable. This will emit the data

.just(new String[]{“1”, “2”, “3”, “4”}); //Operator

Paso -2 Crear observador que consume datos:

Observer<String> observer = new Observer<String>() {

@Override

public void onCompleted() {

//…

}

 

@Override

public void onError(Throwable e) {

//…

}

 

@Override

public void onNext(String s) {

//…

}

};

Paso-3 Administrar la concurrencia:

database.subscribeOn(Schedulers.newThread()) //Observable runs on new background thread.

.observeOn(AndroidSchedulers.mainThread()) //Observer will run on main UI thread.

.subscribe(observer);//Subscribe the observer

Reactive X

Se puede encontrar una implementación del paradigma para distintos lenguajes de programación en la librería ReactiveX . Esta cumple con los requisitos que hemos mencionado previamente.

Tal como reza la propia web:

ReactiveX es una librería para componer programas asincrónicos y basados en eventos mediante el uso de secuencias observables.

Extiende el patrón Observador para admitir secuencias de datos y / o eventos. Además propone operadores que permiten componer secuencias de forma declarativa; mientras abstrae el subprocesamiento de bajo nivel como el threading, sincronización, seguridad de subprocesos, estructuras de datos concurrentes y E/S no bloqueante.

 

Reflexiones finales

Tal como hemos observado en este artículo, la necesidad de la programación reactiva viene de la mano de mejorar la experiencia de usuario y generar sistemas y aplicaciones más responsivos, resilentes y elásticos.
Los sistemas se basarán en tres componentes principales: Observables, Observers y Schedulers.
La librería ReactiveX, que nos proporcionará los mecanismos basados en mensajes para controlar los actores del sistema e implementar de una manera elegante este paradigma.
En el siguiente artículo veremos algunos casos de uso de la programación reactiva, así como ejemplos en Javascript y Java.

 

 

 


Ricardo Ahumada


Entradas relacionadas
Nuestro sitio utiliza cookies para análisis. Si no estás seguro de ello, echa un vistazo a nuestra política de privacidad.