Red Entities
Un artículo de Rafa G. Blanes
He publicado en GitHub un nuevo repositorio de una librería extraída de todo mi trabajo realizado por el momento en Hub de Libros.
Se trata de Red Entities, un object mapper y query builder con el que hacer transparente el acceso a las entidades de datos con algunas particularidades que me animaron hace un año a construirlo y no usar otro tipo de proyectos similares. De momento, es compatible con varios sabores de Mysql y Sqlite y probado con Node.js 10, 12, 13 y 14.
Aunque he utilizado mucho GitHub y tengo publicados varios repositorios, con Red Entities he trabajado mucho en la documentación y en el ciclo de vida para publicar un proyecto así y que esté disponible también como paquete en NPM.
Tal y como comento en la documentación, hay una intención de diseño detrás de Red Entities, relacionada con la concepción de proyectos altamente escalables, esto es, proyectos que van a crecer mucho en todos los sentidos y que, además, no tenemos ni idea de hacia dónde se van a dirigir.
En software hay un principio que no siempre tenemos en cuenta: proyecto acotado, claro, con requisitos muy claros, que comienza y termina y punto... se puede hacer con cierto diseño y arquitectura y el ciclo de vida y metodología que elijas. Proyecto no claro, producto mínimo viable, requisitos impredecibles, reglas de negocio cambiantes... hay que hacerlo con un diseño, concepción y arquitectura totalmente diferente y una metodología ágil más abierta e iterativa. Sutil de pillar, pero con profundas consecuencias en el software que se genera de un modo u otro.
Y esto afecta, claro está, a cómo persisten los datos, cómo se utilizan y cómo evolucionan las bases de datos: al evolucionar las reglas del negocio y funcionalidad, lógicamente, las estructuras de bases de datos (sean las que sean), también cambiarán. Para que esto no suponga una pesadilla, hay que aplicar un enfoque, digamos, más laxo, con sus inconvenientes, claro, pero con las ventajas que comento en este post.
Digresión...
Sé que a algunos les parecerá extraño lo que voy a indicar a continuación, porque va en contra de ciertos paradigmas muy asentados e incluso aprendidos en nuestra etapa académica:
Los modelos de datos relacionales son un obstáculo en sistemas que van a crecer mucho y cuya evolución desconocemos totalmente.
Si cuentas con un proyecto cerrado (se sabe lo que hay que hacer, la lógica de negocio está muy bien especificada, y, además, se entrega y punto, poco más va a ser cambiado), entonces es perfecto utilizar como repositorio de datos con sus entidades relacionadas (relaciones 1..n, 1..1, etc.), que son restricciones sobre el uso y distribución de los datos entre diferentes tablas, manteniendo así en todo momento la integridad referencial y facilitando cosas como la eliminación en cascada, transacciones, rollbacks, etc. Incluso ligar el proyecto a una tecnología concreta de servidor de base de datos (Sql Server, Postgresql, Mongo, etc.)
Sin embargo, siempre (SI-EM-PRE) que he visto un proyecto que ha crecido mucho con funcionalidad inimaginable al principio y se ha querido mantener un enfoque relacional en los datos a toda costa, siempre, digo, el resultado ha sido horroroso: un número exagerado de tablas, reduncancia de datos, complicación extrema en las migraciones y todo cogido con pinzas. Recuerdo ese proyecto con más de cien tablas (sí, más de cien) y tantas líneas indicando sus relaciones que aquello parecía el mapa del metro de Londres. ¿Resultado? Imposible de mantener, cualquier cambio suponía un enorme dolor de cabeza, fallos en producción por efectos colaterales imposibles de prever y ya no hablemos del rendimiento.
En estos casos, hace falta un enfoque diferente, más bien pensar con un paradigma diferente.
Hace falta una componetización radical del sistema, en donde la funcionalidad está distribuida en pequeños componentes que se hablan entre ellos cada uno con su dominio de trabajo. La funcionalidad de alto nivel se implementa mediante la orquestación de los mismos.
Por su parte, puesto que su tamaño es por definición pequeño, cada componente maneja por tanto un conjunto reducido de entidades de datos, sobre los que realiza básicamente actividades CRUD.
Y nada más, porque esta es la clave de construir sistemas grandes que evolucionan mucho.
Este enfoque nos da una libertad extraordinaria para evolucionar el sistema (con más componentes, con cambios en los modelos de datos, etc). En Hub de Libros, sistema donde he empleado claramente este paradigma, además de haber más de setenta componentes actualmente, tan solo dos utilizan en su modelo de datos tres entidades (tablas) diferentes, con poco acoplamiento además y, en total, el sistema cuenta con seis bases de datos diferentes, cada una con un propósito distinto y una política de backups también diferente.
Claro, lo que ganamos por un lado, requiere pagar un precio, como siempre: nos quedamos sin la maravillosa integridad referencial, pero el precio bien vale la pena. Ésta hay que mantenerla programáticamente. No obstante, y después de trabajar en dos proyectos que siguen creciendo con este paradigma, eso no es un problema relevante dadas las ventajas de manejar pequeños modelos de datos para componentes pequeños.
Red Entities, proyecto que ahora libero a la comunidad para su libre uso, permite eso precisamente: definir un esquema (modelo en un objeto json), implementarlo con una línea de código (crear su estructura de datos en Mysql o Sqlite) y una sintaxis insultantemente sencilla y rápida de escribir para realizar las operaciones CRUD habituales, mediante lo que denomino selectores y que me recuerda en cierto modo a la eficacia de jQuery.
Sé que hay otros proyectos similares y mucho más ambiciosos, pero dada la importancia de esta librería en Hub de Libros, decidí desarrollarla desde casi desde cero después de haber trabajado el año anterior en un concepto parecido pero para Redis (Blue Entities) y evolucionarla para no depender en Hub de Libros en este punto tan importante de terceros. No he encontrado, digo, un object-mapper & query builder con las características para implementar componentes como se hace en Hub de Libros y los proyectos en los que trabajaré próximanete dentro de Mantra Framework.
Sin entrar en detalles, punto importante: la actualización de un esquema a otro (por un cambio en una propiedad, otro índice, o cualquier otro cambio), es trivial de realizar, algo que ahora mucho esfuerzo en la vida de cualquier proyecto.
Confío en que sea de utilidad y que haya quienes se animen a utilizar Red Entities en sus propios proyectos.