Uno de los mitos en el desarrollo web es que los developers especializados en frontend es que en su trabajo no involucra la construcción de bases de datos, solo consultas a APIs.
Nada mas lejos de la verdad, si bien la fuente de la verdad absoluta siempre serán los datos provenientes de una API. La data de los endpoints por si sola no tiene significados hasta que no la estructuramos y la usamos.
Cuando definimos el estado de una aplicación, estructuramos data de modo que la UI puede mostrar información y/o ciertas acciones pueden ser permitidas o negadas.
Otro escenario es cuando queremos que cierta data persista pero solo en el navegador. ¿Porqué no todo en el server? Bueno crear/mantener un endpoint involucra un costo y hay veces que la persistencia que se busca no requiere de un servidor (ejemplo: un token de autenticación).
Bueno continuamos, normalmente la data del estado de una aplicación esta in-memory y cuando abrimos otra tab, tiene su propio stack de memoria donde la data no se comparte.
El browser tiene varios mecanismos de storage: LocalStorage, SessionStorage, Cache API, IndexedDB, etc. Cada uno tiene un propósito pero por el momento no ahondaremos en eso, me enfocaré en que estos nos ofrecen persistencia a nivel dominio, lo cual es útil para poder tener datos que sean consistentes en todas la tabs abiertas en nuestra web en un navegador y en algunos casos poder hacer sincronización de datos con el servidor cuando por alguna razón perdemos la conexión o estamos en modo "offline".
Consideraciones
Ya vimos que tenemos varios storages para persistir datos, ¿y?. La persistencia en el browser involucra ciertas consideraciones que hay que tomar en cuenta para la estabilidad y el buen funcionamiento de nuestra web
Persistencia temporal
La data del browser (storage) puede ser borrada ya sea por el mismo browser o por el usuario. Esta consideración nos agrega un constraint.
En ningún momento des por hecho que va a existir data
Hay data que corresponde a operaciones sensibles, como un flujo de pagos que es preferible manejar la persistencia a nivel servidor y quizas solo persistir en el browser el resultado final porque la data podría ser borrada en cualquier momento, cosa que no pasaría en una base de datos en el servidor.
Limites y permisos
Si bien los equipos de computo tienen cada vez mas potencia, también es cierto que la exigencia a estos equipos es mayor y los recursos son limitados. A diferencia de un servidor donde como developers tenemos el poder absoluto del sudo (chiste linuxero). En el browser podríamos tener permisos o no, tener espacio o no. Para resolver estas preguntas tenemos el StorageManager API.
Esta API nos ofrece métodos como estimate que nos regresa una promesa que objeto con la quota (espacio máximo que podemos usar), usage (lo que hemos usado) y usageDetails.
Cada browser tiene sus políticas para el storage, la quota puede variar incluso la parte de permisos. También hay que mencionar que cada storage tiene también sus limitantes, esto nos deja otro constraint.
No asumas que toda la data que intentas guardar va a persistir
Si quieres saber mas del Storage y la persistencia, te recomiendo leer este artículo.
El storage manager tiene 2 métodos llamados persist y persisted que nos ayudan con la cuestion de permisos.
Nota: Los storage se categorizan en 2 "Best Effort" y "Persistent". Para mas detalles consulta este artículo. También te recomendamos esta referencia de como el browser administra las quotas.
Conclusiones
La persistencia involucra factores a tomar en cuenta como Permisos y Quotas. Y estos pueden ser determinados por las políticas de cada navegador y el dispositivo donde se ejecuta nuestra web.
¿Vale la pena saber esto? Claro, el tener conocimiento de estas APIs, sus beneficios y sus limitantes nos da herramientas para brindar una mejor experiencia a los usuarios y ellos son lo mas importante.
Top comments (0)