El título no es un cebo para hacer clic, el mensaje es abrupto "¡Deje de usar el almacenamiento local!" No hay ambigüedad aquí y no nos tomamos de la mano ni cantamos Kumbayá para suavizar el golpe.
¿Problemas con el almacenamiento local?
localStorage surgió alrededor de 2009 como un almacenamiento basado en cadenas de 5 MB. Vayamos al grano con algunos puntos, ya que nuestra capacidad de atención está desordenada estos días:
- Una colección de cadenas: solo puede almacenar cadenas. Si desea almacenar o recuperar, debe serializar y deserializar. Si lo olvida, puede estar expuesto a peculiaridades que han sido responsables de todo tipo de sitios web rotos. P.ej. Cuando almacena "verdadero" o "falso", también hay un posible "nulo", "indefinido" o "" a tener en cuenta dependiendo de su configuración.
Sin datos estructurados: JavaScript tiene algo llamado algoritmo de clonación estructurado. Realmente necesitas saber que esto existe. Las API modernas y las API actualizadas, como postMessage, WebWorkers, IndexedDB, Caches API, BroadcastChannel, Channel Messaging API, MessagePort y History API, utilizan datos estructurados. Resuelve el problema de serializar y deserializar JSON dentro de una aplicación. localStorage no se ha actualizado con esta función y no hay discusiones sobre esto en el futuro. - Compromisos de seguridad comunes: para aclarar, nunca debe almacenar datos confidenciales en ningún almacenamiento persistente que no haya sido diseñado específicamente para ello. Los desarrolladores todavía suelen almacenar ID de sesión, JWT, detalles de tarjetas de crédito y claves API en localStorage. Es un truco de seguridad muy común porque es tan fácil como window.localStorage.
- Rendimiento: Históricamente, el almacenamiento local tuvo sus momentos lentos, aunque se han realizado algunas optimizaciones a lo largo del tiempo que lo llevan a un rendimiento razonable. A pesar de esto, todavía no es deseable para aplicaciones simultáneas que necesitan transacciones frecuentes. Si realiza una evaluación comparativa, digamos, con la última MacBook sin limitar el rendimiento, es posible que no comprenda las implicaciones de costos en dispositivos de baja potencia.
- Limitación de tamaño: localStorage tiene un límite de 5 MB que está sujeto a desalojo. Esta es una cantidad muy pequeña para aplicaciones modernas. Es difícil almacenar medios codificados con una cantidad tan pequeña. Y no está escrito en piedra, al igual que todo el almacenamiento persistente en la web localStorage puede ser desalojado por el navegador en algún momento. Se espera que usted administre esa parte del ciclo de vida de los datos, a pesar de que no haya ningún recordatorio para hacerlo.
- Sin acceso para Web Worker: espero que comprenda que localStorage no es una API para el futuro ni para aprovechar la concurrencia, algo que se esfuerza en dispositivos de baja potencia.
- Sin atomicidad ni aislamiento: localStorage no garantiza la atomicidad en múltiples operaciones. No existe ningún mecanismo de bloqueo para garantizar lo que se escribe o para evitar que se sobrescriba la información.
- Sin separación de datos ni alcance de origen granular: localStorage es solo un objeto de cadenas, no hay separación de datos, los datos del usuario se mezclan con los datos de la aplicación. Aunque utiliza la política del mismo origen, no hay forma de restringir los datos por un dominio o subdominio particular al que tenga acceso. Esto puede crear trabajo duplicado cuando se cumplen los estándares GDPR en múltiples dominios.
- Sin transacciones agrupadas: localStorage no tiene transacciones según la definición de la base de datos, pero tampoco tiene forma de agrupar operaciones. Cada operación es sincrónica, no aislada y sin bloqueo.
- Errores de serialización: muchos sitios web funcionan con un estado defectuoso debido a una mala gestión del almacenamiento local. Desde el momento de escribir este artículo, el año pasado, como cliente, tres servicios web diferentes me dijeron que "borrara tu caché", lo cual descubrí que se debía a una gestión inadecuada del almacenamiento local. Si no está familiarizado con los errores al almacenar datos en localStorage, es posible que esté creando errores en su aplicación que quizás nunca encuentre personalmente. Estos errores tipográficos no siempre son obvios, especialmente para los nuevos desarrolladores.
- Operaciones de bloqueo síncronas: localStorage no es asíncrono y bloqueará el hilo principal. Incluso puede hacer que tus animaciones se entrecorten dependiendo de cuánto leas/escribas y con qué frecuencia. La asincronicidad es fundamental para crear aplicaciones fluidas, especialmente para dispositivos móviles
¿A dónde fue WebSQL?
WebSQL pretendía ser una interfaz de base de datos SQL simple para la web. Tuvo cierto soporte decente, pero eventualmente enfrentó desafíos que llevaron a su desaprobación.
¿Por qué dejaron caer al bebé?
- Implementación de un solo proveedor: WebSQL era principalmente una cuestión de kit web (inicialmente Chrome y Safari). La falta de soporte de otros proveedores importantes de navegadores (Mozilla y Microsoft) hizo que la adopción por parte de los desarrolladores fuera casi inexistente en el mundo comercial.
- Sin estandarización del W3C: esto es crucial para la adopción. W3 pareció abandonar la propuesta en 2010.
- Competencia con IndexedDB: IndexedDB estaba ganando más tracción y soporte durante el auge de WebSQL. A diferencia de WebSQL, IndexedDB fue diseñado para ser una solución estándar para varios navegadores.
- Preocupaciones de seguridad: varios desarrolladores y especialistas en seguridad mostraron preocupaciones con respecto a la seguridad de WebSQL. Se mostraron escépticos ante varios aspectos, incluida la falta de controles de permisos y las vulnerabilidades de estilo SOL.
- Con el tiempo, IndexedDB se convirtió en el estándar "recomendado" para el almacenamiento del lado del cliente, siendo visto como más robusto y compatible con todos los navegadores. Pero, ¿de qué sirve "recomendar" cuando la mayoría de los desarrolladores front-end experimentados en el momento de escribir este artículo lo han evitado como si fuera una plaga?
- A pesar de sus deficiencias, en ese momento WebSQL era muy elogiado entre la comunidad web y era un competidor digno.
¿Qué pasa con las cookies?
Las cookies fueron creadas en 1994 por Lou Montulli, programador de navegadores web de Netscape Communications.
Algunos de ustedes ni siquiera habían nacido cuando las cookies estaban arruinando todo. El título de este artículo debería ser "Dejar de usar cookies y almacenamiento local", pero es una lucha muy difícil (sí, deberíamos usar cookies seguras).
- Limitaciones de tamaño: las cookies suelen estar limitadas a aproximadamente 4 KB por dominio.
- Datos enviados con cada solicitud: las cookies se envían con cada solicitud HTTP al dominio asociado. Si no es necesario transmitir sus datos con cada solicitud, esto puede generar una sobrecarga innecesaria y un mayor uso del ancho de banda.
- Preocupaciones de seguridad: las cookies son más susceptibles a XSS. Debido a que las cookies se incluyen automáticamente con cada solicitud al dominio, pueden ser atacadas por scripts maliciosos.
- Caducidad y vida útil: las cookies fueron diseñadas para caducar en una fecha determinada.
- Mayor latencia: debido a que las cookies se incluyen automáticamente en cada solicitud HTTP al dominio, generalmente generan una mayor latencia, lo que hace que la carga de su sitio web sea más lenta.
Por qué IndexedDB
- Mejor rendimiento: a diferencia de localStorage, IndexedDB funciona de forma asincrónica, lo que evita operaciones de bloqueo. (La API se basa en eventos, no en promesas)
- Amplia cuota de almacenamiento: IndexedDB proporciona una cuota de almacenamiento mayor (dependiendo del navegador, el sistema operativo y el almacenamiento disponible) en comparación con el límite de 5 MB de localStorage.
- Fiabilidad y datos estructurados: almacenar y recuperar datos en localStroage puede producir resultados impredecibles si no se hace correctamente. IndexedDB reduce la coerción de tipos común y adopta el algoritmo StructuredClone, lo que garantiza la integridad de los datos.
IndexedDB es la excepción a la regla de evitar dependencias. Piense en IndexedDB como una base de datos backend; probablemente desee un ORM o una biblioteca de bases de datos para procesar consultas. Esto es similar a querer una biblioteca IndexedDB, excepto que la API de IndexedDB es atroz.
La razón por la que desea utilizar una biblioteca es porque principalmente:
- Se basan en promesas
- Son más fáciles de usar
- Reducir el código repetitivo
- Concéntrate en cosas más significativas.
- Personalmente, no recomiendo el uso de bibliotecas grandes para IndexedDB porque lo que estás tratando de lograr no requiere más que un puñado de kB de un solo dígito. El exceso de bibliotecas IndexedDB no hará nada significativo para sus escenarios del mundo real.
El único problema que encontré con la mayoría de las bibliotecas IndexedDB es cómo están orientadas principalmente al control de versiones, lo que probablemente no necesites en absoluto, especialmente si solo estás buscando una alternativa razonable de almacenamiento local.
Complemento rápido: creé db64, una biblioteca para centrarme solo en los aspectos más relativos de IndexedDB.
Si necesita control de versiones o cursores, le recomendaría idb, que es una biblioteca completa que cubre bien todos los casos específicos.
Conclusión
Aunque no siempre es posible, hoy en día debemos intentar evitar el uso de almacenamiento local.
Los nuevos desarrolladores tendrán un conocimiento más significativo y reutilizable para jugar con Promise(), asíncrono/espera y datos estructurados que tratar de descubrir por qué el número "0" hace que sus condiciones sean verdaderas o por qué su usuario enojado obtuvo entregas nulas.
En resumen, hay una ventaja en la velocidad: puede almacenar tipos de manera confiable e incluso puede usar cursores para iterar sobre las entradas. Con esta tecnología, podría crear un motor de búsqueda del lado del cliente con búsquedas de datos acumulados que no hagan que sus animaciones se inquieten, como ocurre con localStorage que las bloquea e interfiere con ellas.
IndexedDB se describe comúnmente como "de bajo nivel". IndexedDB no tiene absolutamente nada de bajo nivel, es solo una API con una sintaxis anticuada y poco amigable. Pero eso no niega sus capacidades subyacentes, de ahí el uso común de la biblioteca.
No necesariamente necesita usar la API directamente a menos que lo desee, pero tiene sentido usar una pequeña biblioteca contenedora o, por qué no, crear la suya propia.
Artículo original:
https://medium.com/@julienetienne/stop-using-localstorage-64a6d6805da8
Desarrollo con Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter