Los beneficios completos de la programación reactiva entran en vigencia solo si toda el stack de tecnologías es reactiva y si todos los componentes participantes (código de aplicación, contenedor de tiempo de ejecución, integraciones) respetan la ejecución diferida, las API sin bloqueo y la naturaleza de flujo de flujo de datos, básicamente siguiendo los supuestos subyacentes .
Si bien es posible llevar componentes no reactivos a una aplicación que está escrita en un estilo funcional-reactivo, el resultado neto es que los beneficios reales esperados, disminuyen. En el peor de los casos, hay poca o ninguna diferencia en el comportamiento del tiempo de ejecución. Sin embargo, la programación reactiva ayuda a mejorar la legibilidad del código.
Si observamos el ecosistema reactivo, descubriremos varios frameworks, bibliotecas e integraciones. Cada uno de ellos tiene sus puntos fuertes específicos. Muchas áreas funcionales están bien cubiertas, ya sea con un enfoque genérico o dentro del contexto de un framework reactivo particular.
Java utiliza JDBC como tecnología principal para integrarse con bases de datos relacionales. JDBC es de naturaleza bloqueante: no hay nada sensato que se pueda hacer para mitigar la naturaleza bloqueante de JDBC. La primera idea de cómo hacer que las llamadas no se bloqueen es descargar las llamadas JDBC a un ejecutor (generalmente grupo de subprocesos). Si bien este enfoque funciona, viene con varios inconvenientes que descuidan los beneficios de un modelo de programación reactiva.
Los grupos de subprocesos requieren, no es de extrañar, subprocesos para ejecutarse. Los tiempos de ejecución reactivos suelen utilizar un número limitado de subprocesos que coinciden con el número de núcleos de CPU. Los hilos adicionales introducen gastos generales y reducen el efecto de limitación de hilos. Además, las llamadas JDBC generalmente se acumulan en una cola, y una vez que los hilos están saturados de solicitudes, el grupo se bloqueará nuevamente. Entonces, JDBC ahora no es una opción.
Hay un par de controladores independientes, como el reactive-pg-client. Estos controladores vienen con una API específica del proveedor y no son realmente adecuados para una adopción más amplia.
Como no hay una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Se les ocurrió R2DBC que significa Conectividad de base de datos relacional reactiva. Pero eso es otra Historia y va ha ser contada en otro post ...
Dejo link:
