0

Pasado, presente y futuro de la persistencia en CRIAX-SDK

28Nov
en CRIAX-SDK, Firefox OS, Javascript

Este articulo debió ser publicado hace un tiempo, pero por cuestiones de trabajo no había podido.

Esta investigación nace partiendo de la necesidad del desarrollo de aplicaciones para Firefox OS con CRIAX-SDK donde se pudieran almacenar grandes cantidades de datos y pudieran ser manipulados como en bases de datos relacionales, teniendo acceso a funcionalidades como autoincremento, relaciones entre tablas, entre otras, de manera tal que se pudiera hacer uso de las clases ya presentes para el desarrollo de aplicaciones de escritorio.

Introducción

Actualmente Firefox OS no soporta de manera oficial SQLite, para llevar a cabo la persistencia de información en el desarrollo de aplicaciones para el sistema, pues a diferencia de otros sistemas el ideal es que toda tarea sea llevada a cabo mediante las tecnologías usadas en la Web.

La persistencia en las aplicaciones para Firefox OS. Alternativas

Al momento de investigar como poder persistir grandes cantidades de datos desde JS aparecieron varias alternativas como:

TaffyDb: que es una librería de JS que brinda funcionalidades de base de datos a un conjunto de objetos literales de JS (JSON), que asemejan a registros de una tabla, y agrupados en un arreglo asemejan la información de la tabla misma. Entre sus características se encuentran:

  • funcionar en distintos navegadores
  • funciones de insertar, actualizar y eliminar
  • compatible con librerías de terceros como JQuery, Dojo, YUI
  • muy rápida
  • puede ser fácilmente extensible con funcionalidades propias
  • licencia BSD

Nuevamente la carencia debido a las necesidades particulares radica en que el esquema de Taffy sirve solamente para una “tabla”. Que sucede entonces cuando “hemos normalizado” la información y necesitamos obtener información de varias “tablas”?

JSONSQL: quizás uno de los primeros intentos por ejecutar consultas SQL a datos en JSON. Bajo la licencia de Apache, solo se podía ejecutar consultas de selección.

TrimQuery: es una librería que forma parte de un proyecto iniciado en Google, bajo la licencia 2 de Apache, llamado TrimPath. Es un script que permite usar sentencias SQL para obtener datos contenidos en un objeto JSON. Entre las características que posee se encuentran:

  • codificado en JS estándar
  • admite SELECT … FROM
  • cláusulas WHERE
  • ordenación (ORDER BY) de varias columnas de forma ascendente (ASC) y descendente (DESC)
  • alias (AS)
  • agrupaciones (GROUP BY y HAVING)
  • funciones: SUM, COUNT y AVG
  • joins
  • LIMIT y offsets, parametrización
  • parser de SQL
  • definición de esquema
  • escape automático de datos

Con sentencias SQL bastante amplias pareciera la opción ideal a pesar de tener en contra que no soporta sentencias de SELECT del tipo:

  • BETWEEN
  • IN (for lists and for sub-queries or nested SELECT’s)
  • ANY
  • EXISTS
  • DISTINCT
  • AVG DISTINCT, SUM DISTINCT, COUNT DISTINCT
  • LEFT OUTER JOIN
  • RIGHT OUTER JOIN
  • FULL OUTER JOIN
  • UNION, EXCEPT, INTERSECT

A pesar de ello uno de los elementos que más llaman la atención de esta librería es que internamente hace uso de un lenguaje de sentencias TQL, lo que le permite convertir las consultas SQL a TQL pareciendo a tareas que llevan a cabo algunos ORM. Al igual que la librería Taffy, agrupa los datos de una tupla en un objeto plano y una tabla en un arreglo de objetos planos. Por otro lado destaca su flexibilidad al permitir la representación de varias tablas y su relación. Todo ello con la condición de definir un esquema muy sencillo primeramente de las “tablas”. Otra de las características que destaca de la librería es la posibilidad de debuguear las consultas realizadas, las cuales son validadas bajo las sentencias de SQL.

Definición de columnas

La definición de columnas es una estructura de objetos planos de JS, donde el primer nivel es el nombre de las “tablas” y los valores consisten en la definición de la información de las columnas.

TQL

Internamente la librería convierte el código SQL a TQL embebido en el mismo JS, aunque la recomendación es que se utilice SQL como lenguaje de sentencias. De esta manera se libera al parser de JS de evaluar las sentencias y por lo tanto de hacer el trabajo duro.

De esta manera entre las librerías la elección fue obvia, pues además la librería TrimQuery contaba con mejor documentación que el resto investigadas.

Pasado

Seleccionado el mecanismo para manipular los datos, solo quedaba en donde se guardarían los mismos, para que realmente se persistieran. En el día de hoy HTML5 tiene muy buenos mecanismos para persistir información incluso cuando se han cerrado las páginas.

Hay varias opciones para almacenar información del lado del cliente, pero para almacenar grandes cantidades de datos de manera organizada no tanto. De lleno tendría que ser descartado WebSQL, pues no es soportado por Firefox y de hecho las aplicaciones móviles se construirían para Firefox OS. Por lo tanto nos quedaban las alternativas de Web Storage. Con una API simple basado en el almacenamiento de par clave, valor se ofrece sessionStorage y localStorage. Obviamente necesitamos persistir la información incluso cuando se cierre la aplicación o se apague el teléfono, por lo cual localStorage es la alternativa más viable.

El problema viene al momento de almacenar más de 5Mb de información el cual es el límite de localStorage, entonces definitivamente no es la alternativa, pues se piensa en poder almacenar miles de datos.

IndexedDB: es una manera de persistir los datos en el navegador del cliente, usada principalmente para almacenar grandes cantidades de datos. Permite guardar información de objetos planos de JS los cuales pueden ser indexados mediante una clave, pudiendo guardar información a través de diferentes dominios pero impidiendo su acceso. Nacido como una alternativa a WEB SQL que fue desechado el 18 de noviembre de 2010. Este es un sistema indexado de tablas. Usa principalmente una API asíncrona para el manejo de los datos. Los valores pueden llegar a ser complejos pares de clave: valor, objetos planos de JS. Esta construido sobre un modelo de bases de datos transaccionales, pero no usa el lenguaje SQL para realizar la búsqueda y manejo de datos.

Es un sistema muy potente que a pesar de pequeñas deficiencias como una API complicada es un estándar aun en ascenso. Principalmente la no elección de la misma se debió a no existir una forma intuitiva de implementar relaciones entre tablas basadas en claves foráneas utilizando JOINS.

Es cierto que existen infinidades de librerías que hacen la vida más fácil al momento de trabajar con IndexedDB, pero una de las premisas continua siendo poder ejecutar consultas SQL para manejar los datos, al nivel de complejidad que las mismas proponen.

Presente

Localforage es una librería de JS que permite mediante una API asíncrona almacenar información del lado del cliente. Una capa abstracta para IndexedDB o WebSQL en dependencia de lo soportado por el navegador, mediante funciones tan simples como las de la API de localStorage. Como utiliza funciones asíncronas, la ejecución de las acciones se lleva a cabo mediante callbacks. Una de las características destacadas es que solamente no se almacenan strings como en localStorage sino varios tipos de datos como Blobs, ArrayBuffers, todo tipo de objetos nativos de JS que pueden ser serializados a JSON. Automáticamente la librería selecciona el driver que mejor funcione en el navegador, dando la posibilidad así de aumentar la eficiencia en la ejecución del código. Desarrollada por Mozilla está distribuida bajo la licencia de Apache.

La simplicidad de la librería y el soporte a los 3 métodos actuales para almacenar información del lado del cliente la hacen una elección perfecta.

Futuro

El futuro puede ir por 2 caminos:

  1. El futuro deseado es una API, mediante la cual se puedan llevar a cabo búsquedas complejas de manera sencilla en IndexedDB, como por ejemplo el JOIN de varias tablas dado un criterio de búsquedas. Pues en el trabajo con una “tabla” si es muy sencillo, se complica al momento de manejar varias relacionadas.
  2. El uso de SQLiteJS para la persistencia pero usando por detrás IndexedDB.
Etiquetado en:

Dejar un comentario

¿Eres humano? Entonces resuelve esta operación: * Límite de tiempo se agote. Por favor, recargar el CAPTCHA por favor.