Nueva versión de UGR transparente

Aviso: Este es un post antiguo, puede que su información esté desactualizada. Si está buscando algo sobre un evento actual, tenga en cuenta que puede que este no sea el que busca.

En la Oficina de Software Libre de la Universidad de Granada no paramos de trabajar así que acabamos de terminar una nueva versión de la plataforma UGR transparente que corrige los errores de funcionamiento que existían hasta ahora. Todo el código desarrollado es libre y se puede encontrar en este repositorio de GitHub, así que se interesa conocer mejor el estado del proyecto solo tienes que seguir leyendo.

Motivación de los cambios:

En la versión anterior se producía siempre un error interno del servidor cuando se cargaba una página por primera vez, además de forma intermitente las tablas de las páginas se mostraban vacías. Esto era debido a que por el funcionamiento asíncrono de Node.js, puede ser que la llamada retorne antes de que se completen las operaciones en su totalidad, por lo que se podía producir la situación de que se intentase visualizar una página antes de que la información del contenido que tenía que recuperarse de la base de datos pudiera haber sido recuperada o incluso accedida. Si la página se intentaba mostrar antes de que la base de datos fuera accedida, los recursos no se encontraban creados y por eso siempre daba un error la primera vez que se visualizaba; si la página se intentaba mostrar antes de que la información hubiera sido recuperada, los recursos ahora si existían, pero estaban vacíos por lo que las tablas de la página se mostraban vacías; solo si la llamaba retornaba cuando todas las operaciones habían sido completadas, lo que significa que la página se intentaba mostrar una vez la información ya había sido recuperada completamente de la base de datos, era cuando la página se mostraba correctamente.

Para evitar el error interno del servidor, al arrancar el servidor en transparente.ugr.es se hacía una carga inicial de todas las páginas mediante la orden «curl«, pero el problema de las tablas vacías seguía estando ahí. Como no conseguí encontrar la forma de arreglar estos errores que se producían por la asincronía entre las operaciones, y el uso de la base de datos era similar al de un índice al que igualmente había que introducirle los datos manualmente desde archivos externos JSON, empecé a desarrollar una nueva versión en la que se sustituyera la función de la base de datos con la carga de los archivos JSON directamente desde la aplicación, esto podría solucionar todos estos errores porque el propio Node.js mediante el módulo «fs«, que provee de la funcionalidad para operar con entrada/salida de ficheros, tiene un método para que la lectura de estos archivos se haga de forma síncrona [fs.readFileSync(archivo)]. Como los archivos son leídos de forma síncrona (forma de la que no era posible recuperar los datos de la base de datos), tanto el error interno como el error en las tablas vacías han dejado de producirse debido a que ya nunca se intentará visualizar las páginas antes de que los datos estén cargados.

Comparación de versiones:

En la versión anterior de UGR transparente, desde el archivo principal de la aplicación «app.js» se cargaba el contenido del archivo «config.json» (también en raíz), que tenía la configuración de acceso a la base de datos MongoDB de la que recuperaba el contenido de las tablas que se visualizan en las diferentes páginas de la web; también de dicho archivo, se recuperaba el contenido de las páginas sin tablas: «Inicio«, «Presentación» y página de error; y además la siguiente información sobre el contenido de cada una de las páginas: categoría, colección, contenido, dataset, nombre y plantilla. En la nueva versión, la información de cada una de las páginas se ha movido a archivos JSON independientes: «claustro.json«, «estadistica.json«, etc. (que también son cargados desde «app.js«), el contenido que se recuperaba desde la base de datos se ha introducido también en esos archivos JSON. Todos estos archivos se encuentran en una nueva carpeta «config» situada en raíz, además la información recuperada se ha simplificado a: nombre, plantilla, contenido y datos.

Toda la información cargada desde «app.js» luego es utilizada desde los archivos JS que se encuentran en la carpeta «routes» correspondientes a cada una de las secciones de la página UGR transparente: «administracion.js«, «docencia.js«, «gestionInvestigacion.js» y «normativaLegal.js«. En la versión anterior, se recuperaba la configuración de acceso a la base de datos desde la información cargada, y mediante iteraciones por las colecciones correspondiente a la página a visualizar, se almacena en variables el contenido recuperado, contenido que luego era gestionado cuando Express generaba la página web después de procesar la plantilla Jade pertinente. En la nueva versión, la recuperación de la información está mucho más simplificada porque se obtiene directamente de la información cargada desde «app.js«, recuperando el contenido de los archivos «config.json» y «PAGINA.json«; por ejemplo, para la gestionar la sección «Administración«, en el archivo «administracion.js» se recupera la información de «config.json» que nos dará la dirección del servidor con los datos (open.data.ugr en este caso) y también recupera la información de los archivos «personal.json» para la página «Personal«, «infoEconomica.json» para la página «Información Económica» y «servicios.json» para la página «Servicios«, esta información es la que usará Express para generar la página que se vaya a visualizar.

En las plantillas Jade de la carpeta «views«, también se ha cambiado la forma de acceder a las variables con la información de la página que la plantilla recibe. En la versión anterior, los valores del contenido eran recibidos en arrays bidimensionales con el contenido recuperado de la base de datos, que tenían que ser procesados mediante varios bucles for; en la versión actual, los valores de contenido son recibidos directamente como campos de archivo JSON, por lo que pueden ser fácilmente accedidos como un array unidimensional.

Ventajas e inconvenientes:

Como ventajas encontramos en primer lugar, que al eliminar MongoDB se liberan una gran cantidad de recursos del sistema; además, a falta de pasar los test pertinentes, no se ha vuelto a producir ningún fallo en la carga o visualización de los datos en las páginas. Como ya no dependemos de la base de datos, el trabajar directamente con los archivos JSON nos da una mayor manejabilidad como es que se puedan adaptar en cualquier momento y directamente la estructura y contenido de los archivos según las necesidades.

Un inconveniente que existe en este versión es algo que también existía en la versión anterior, y es que los datos provienen de archivos JSON que hay que crear manualmente, por lo que si el número de datos es elevado, el proceso de introducción de datos se puede volver realmente pesado.

Siguiente trabajo:

El problema de tener que crear los JSON directamente se podría solucionar si se pudieran recuperar los datos directamente desde el servidor de open.data.ugr, como ese portal esta construido con CKAN que usa una base de datos PostgreSQL para almacenar los datos y además provee de una API para acceder a los datos, sería deseable encontrar la llamada o llamadas que permitieran recuperar los mismos datos que se encuentran en los archivos JSON, algo que todavía no he conseguido encontrar. Una vez que se encontraran estas llamadas, los datos se podrían recuperar directamente utilizando el backend Recline.js que nos permite fácilmente recuperar la información (ejemplo en el script «prueba_recline.js» de la carpeta «public/script«) y trabajar con ella usando las funciones de las que nos provee, o bien, recuperar la información mediante consultas AJAX (ejemplo en el script «prueba_acceso.js» también en la carpeta «public/script«) y trabajar con funciones que desarrollemos para trabajar con la información recuperada.

Lo próximo en lo que voy a trabajar es en realizar los test de cobertura, siendo lo primero todo lo que se refiera al acceso a datos. Empezaré viendo como utilizar el framework de test «Mocha» para todo esto. Otros aspectos que quedan pendientes son la integración continua y el aprovisionamiento.