Junto a la proliferación de los dispositivos móviles llegaron una serie de características, bajo el manto de paradigmas, que pregonaban las buenas prácticas reduciendo el consumo de datos en móviles, y evitando la pérdida de conectividad y, por ende, la información del usuario.
🌟Offline-first es su nombre y, combinando Service Workers y Cache Storage conseguimos mejorar la UX cuando el dispositivo pierde conexión o el servidor está sin dar servicio.
Offline-first junto a Service Workers y Cache Storage, nos permite “instalar” una copia local de un sitio web o PWA, en el navegador del usuario, para que ésta siga funcionando ante una pérdida de conectividad con Internet.
Service Workers
Podemos definir a un Service Worker como una aplicación agnóstica, que interactúa entre el sitio web (o PWA), el web browser, y la red (cuando esta última es accesible. Permite crear, entre otras cosas, experiencias offline reales, tal como lo permite cualquier otra aplicación de escritorio o móvil.
El service worker intercepta las peticiones de red del navegador web, y las dirige a Internet si hay conexión, o busca la información localmente, ahorrando un tráfico de datos de red y/o evitando un “error jurásico” si no existe conectividad.
Cache Storage
La funcionalidad de Cache Storage permite generar un cache o espacio de almacenamiento local, para todo un sitio web, o parte de él, permitiendo así disminuir las peticiones remotas, y ganando velocidad de respuesta. De esta forma, Cache Storage se convierte en una especie de Proxy local, que atiende las peticiones del Service Worker, solicitando una página web y todos sus elementos vinculados.
¿Y para qué necesitamos esto?
Como bien dijimos en el apartado Cache Storage, velocidad de respuesta, disminución del consumo de datos remotos (menos datos móviles usados, menos trabaja el servidor remoto respondiente peticiones) y, la gran estrella de todo es, la disponibilidad 100% de nuestro sitio web o PWA. Esto permite responder así al paradigma offline-first, sabiendo que más del 50% de la población mundial, accede a Internet desde un dispositivo móvil.
¿Qué es UpUp JS?
Considerando que el uso de Service Worker y Cache Storage local, requiere de una curva de aprendizaje muy amplia, UpUp JS llegó hace unos años, para simplificarnos la vida a nosotros “desarrolladores ágiles”, que buscamos resolver todo sin mucha complicación. UpUp nos brinda a través de dos archivos que conforman esta librería, todo lo necesario para simplificar la integración de SW en nuestros desarrollos web, y poder generar un cache local integrando dos formas muy fáciles: fallback Offline-Page o un Cache Local de archivos.
Cómo integrar UpUp JS
Lo primero que debemos hacer, es descargar la librería con sus dos archivos principales, del repositorio oficial: https://github.com/TalAter/UpUp/tree/master/src. Encontraremos dos archivos:
Upup.sw.min.js: este archivo contiene toda la estructura necesaria de un Service Worker, para que se instale al iniciar nuestro sitio web, y se inicialice en el navegador web del usuario. De esta forma, quedará operativo, listo para hacer su tarea de sincronización de caché.
Upup.js: este otro archivo, es la librería que necesitamos sumar a nuestro proyecto, la cual nos permitirá desde un único método, controlar la caché de nuestro sitio web en el dispositivo del usuario, o ejecutar una página web offline en modalidad fallback.
Sumemos ambos archivos a nuestro proyecto web, dejando los mismos en la raíz de nuestro sitio. El Service Worker, ya sea el de Up Up o cualquiera que creemos manualmente nosotros, siempre requiere estar situado en la raíz de nuestro sitio web.
A continuación, declaramos ambos archivos de la librería UpUp, usando el tag "script", dentro del apartado "head" del documento HTML principal. Seguido a ello, creamos un tercer archivo JS, donde llamaremos el método de UpUp que nos permite controlar el caché. En este ejemplo, nombré este tercer archivo, como offline.js:
<head>
...
<script src="upup.sw.min.js"></script>
<script src="upup.js"></script>
<script src="offline.js"></script>
</head>
Verificar la activación del Service Worker
Declarado el SW de la librería que acompaña a UpUp, iniciemos nuestro proyecto en el web server local. Abramos luego Herramientas para el Desarrollador - Application - Service Worker. Allí veremos la “luz verde” cuando el SW se instaló exitosamente en el navegador web, junto al mensaje “activated and is running”.
Estrategias de caché con UpUp
Las dos principales estrategias de caché que UpUp nos brinda, son:
- Content-url: generar un archivo del tipo fallback. Debe estar conformado por un HTML, con un mensaje amigable, que le notifique al usuario sobre la pérdida de conexión a Internet, y que el sitio o aplicación web, requiere conectividad para funcionar de forma óptima. Dicho archivo HTML deberá contener CSS y JS acorde, en el caso de querer darle un look and feel óptimo al mensaje.
- Assets: a través de este apartado, generamos un array de los archivos a alojar en el caché local, que permita, Service Worker mediante, que el sitio o aplicación web siga siendo funcional, aún sin conectividad.
Estrategia fallback
Veamos a continuación cómo establecer la primera de las estrategias. La misma está pensada para los sitios web que son 100% dependientes de Internet, y que no funcionarán cuando se pierde conexión (un portal de noticias, una red social, etcétera).
Creemos para esto un documento HTML nombrado, por ejemplo: offline.html. En este definimos un bloque de código dentro del body, que le comunique al usuario la falta de conectividad.
offline.html
<body>
<div>
<br><br>
<h2>T@sk-it necesita de una conexión a Internet para funcionar de manera óptima.</h2>
<br>
<h1>:(</h1>
<br>
<h3>Intente nuevamente en unos minutos.</h3>
</div>
</body>
Y, en el apartado "head", le agregamos algo de código CSS y JS, que le de vida e interacción al documento HTML:
<head>
...
<style>
body {
color: whitesmoke;
background-color: darkred;
font-family: Arial, Helvetica, sans-serif;
margin-left: 5%;
margin-right: 5%;
text-align: center;
line-height: 50px;
}
</style>
<script>
window.addEventListener("online", () => {location.reload()})
</script>
</head>
Controlamos el estilo del documento HTML, usando el tag "style", y mediante el tag "script", le agregamos inteligencia para que, cuando retorne la conectividad, nos redirija automáticamente al documento HTML principal, simplemente recargando la página.
Finalmente, en nuestro archivo offline.js, nos resta invocar el objeto UpUp, junto a su método start(). Este recibe un arreglo JSON, con el nombre de la estrategia, y el archivo asociado a ella.
UpUp.start({
'content-url': 'offline.html'
});
De esta forma, se activa el caché local, creando una copia del documento HTML integrada al llamado fallback. Esto lo vemos en Herramientas para el desarrollador - Application - Cache Storage - upup-cache-nnnnnn.
Ahora, para probar el funcionamiento de dicha estrategia, aprovecharemos las herramientas para el desarrollador, y usaremos la simulación offline, seguido de un refresco de página para forzar el llamado al fallback offline. Luego, volvemos al estado online, y veremos que nuestra porción de código JS, refrescará el sitio volviendo a poner en funcionamiento nuestra sitio o aplicación web.
Estrategia cache completo
Probemos a continuación la estrategia mediante assets. Para ello, debemos hacer un inventario de todos nuestros archivos importantes, que deben ser instalados en el caché local del navegador web. Este caché queda asociado al sitio web, por lo cual no puede interactuar de forma directa con otros sitios web, ya sea offline u online. Armaremos el código para el método start(), que permita cambiar la estrategia de cache anterior.
UpUp.start({
'assets': [
'index.html',
'css/materialize.min.css',
'js/materialize.min.js',
'js/JQuery-3.5.1.min.js',
'css/estilos.css',
'js/tareas.js',
'offline.js',
'upup.sw.min.js',
'upup.js'
]
});
Para el caso de librerías de terceras partes (Bootstrap, Materialize, JQuery, etcétera), se puede indicar la ruta absoluta al sitio web real o, mejor aún, copiemos los mismos localmente a nuestro sitio web para ahorrarnos posibles fallos ante la no disponibilidad de los mismos.
Ahora solo nos resta volver a emular la pérdida de conectividad, seguida de un Refresh de nuestra aplicación web. Veremos que la misma sigue funcional, que el Service Worker arrojará un error lógico, por la falta de conectividad y sincronización con el sitio online, pero, aun así, podremos seguir operando con nuestra aplicación o sitio web, gracias a la estrategia de cache local establecida mediante UpUp.
También iremos encontrando en la Consola JS, cada archivo o referencia a una URL, que nuestro sitio web cacheado localmente, intente acceder y no lo consiga.
Conclusión
Mediante estas dos simples estrategias, podemos alertar al usuario la falta de conectividad e invitarlo a seguir utilizando nuestra solución web cuando disponga de la misma, o permitir que el usuario siga trabajando contra el sitio, y sacar provecho de la sincronización posterior, cuando el servicio de internet haya retornado al dispositivo o computadora.
Si recién nos iniciamos en el universo offline-first, UpUp JS es la librería ideal, que nos evita tener que aprender Service Workers y cache storage, y también nos ayuda a obviar la mediana complejidad de Workbox. Con solo una declaración de los archivos de esta librería, más la invocación a un único objeto y método, podemos solucionar el tema de cache storage de una forma muy rápida y ágil, tal como lo requieren los tiempos de desarrollo de software hoy en día.
Recursos
No dejen de visitar el sitio web oficial, del creador de UpUp JS: https://www.talater.com/upup/
Si quieren aprender caché de una forma didáctica, aprovechen el e-book del autor de UpUp, dedicado a las aplicaciones web progresivas: https://www.oreilly.com/library/view/building-progressive-web/9781491961643/
Descarguen el proyecto funcional desde: https://github.com/mobilepadawan/PWAExperts/tree/master/Task-it
Y no dejen de escribirnos ante cualquier duda que les surja 😝
Para dejar tu comentarios debes pertenecer a la Comunidad.