publicado originalmente (2020-11-21) en mi sitio web
IndexedDB es una API de javaScript de bajo nivel que ofrece almacenamiento del lado del cliente.
Permitiendo además almacenar de cantidades significativas de datos estructurados, incluyendo archivos y blobs.
Para búsquedas de alto rendimiento en esos datos, se usa índices, permitiendo busquedas más veloces sobre los datos guardados.
Mientras DOM Storage es útil para el almacenamiento de pequeñas cantidades de datos, no es útil para almacenar grandes cantidades de datos estructurados. IndexedDB proporciona una solución.
Qué tiene que ver esto de IndexedDB con localStorage/sessionStorage?
En la superficie, las dos tecnologías pueden parecer directamente comparables, sin embargo, si pasa algo de tiempo con ellas, pronto se dará cuenta de que no lo son. Fueron diseñados para lograr un objetivo similar, el almacenamiento del lado del cliente, pero abordan la tarea en cuestión desde perspectivas significativamente diferentes y funcionan mejor con diferentes cantidades de datos.
localStorage, o más precisamente Web Storage, fue diseñado para cantidades más pequeñas de datos. Básicamente, se trata de una cadena solo para almacenamiento de valor, con una API síncrona simplista.
indexedDB, por otra parte, fue diseñado para trabajar con cantidades de datos significativamente mayores. Primero, en teoría, proporciona tanto una API síncrona como una asíncrona. Sin embargo, en la práctica, todas las implementaciones actuales son asíncronas y las solicitudes no bloquearán la carga de la interfaz de usuario.
En una reciente revisión de la documentación nos dice:
Las operaciones realizadas con IndexedDB se hacen de forma asíncrona, para no bloquear las aplicaciones. IndexedDB incluía originalmente APIs síncronas y asíncronas. La API sincrónica estaba pensada para ser utilizada únicamente con Web Workers, pero se eliminó de la especificación porque no estaba claro si era necesaria. Sin embargo, la API sincrónica podría reintroducirse si hay suficiente demanda por parte de los desarrolladores web.
MDN Web Docs
Qué navegadores lo soportan?
Para qué me sirve esto?
- sesiones
- perfiles de usuario
- almacen de datos (funciona como una base de datos local)
- PWA's como la de Pokedex
Hay Límites de almacenamiento?
No existe un límite de tamaño para un elemento simple de la base de datos. Sin embargo, puede haber un límite en el tamaño de cada base de datos IndexedDB. Este límite (y la forma en que la interfaz de usuario la hace valer) puede variar de un navegador a otro.
Aunque por lo general cada navegador maneja diferentes tipos de almacenamiento de datos, el almacenamiento viene en dos tipos:
- Temporal: Son datos que no necesitan persistir durante mucho tiempo. Serán eliminados bajo una política de uso menos reciente, cuando se alcancen los límites de almacenamiento.
- Persistente: Estos son datos que están destinados a mantenerse durante mucho tiempo. Sólo se desalojarán si el usuario lo decide.
Por ejemplo, en Firefox el espacio máximo de almacenamiento del navegador es dinámico, se basa en el tamaño de su disco duro. El límite global se calcula como el 50% del espacio libre en disco. Cuando se utiliza el almacenamiento persistente, el usuario recibe una ventana emergente de la interfaz de usuario para avisarle de que estos datos van a persistir, y le pregunta si está conforme con ello. El almacenamiento temporal de datos no provoca ninguna pregunta al usuario.
Mientras que en Chrome, el almacenamiento temporal se comparte entre todas las aplicaciones web que se ejecutan en el navegador. El pool compartido puede ser de hasta 1/3 del espacio de disco disponible. Y una aplicación puede tener una cuota mayor para el almacenamiento persistente que para el temporal, pero debe solicitarlo mediante la API de gestión de cuotas y el usuario debe concederle permiso para utilizar más espacio.
Top comments (0)