Elementos de una aplicación web progresiva

Una aplicación web progresiva es aquella que se comporta de manera tal que los usuarios son capaces de cargar y utilizar dicha aplicación aun estando desconectados del internet. Es decir, se aproxima mas a una aplicación de escritorio.

Ademas de cargar sin conexión, otra característica de las aplicaciones web progresivas es que los usuarios son capaces de crear accesos directos en las pantallas de inicio de los navegadores y acceder a ellas de manera mas rápido que un simple “bookmark“.

Pero se preguntaran; ¿Entonces que necesito para que mi aplicación sea realmente una aplicación web progresiva?

Bien la respuesta es simple, se necesitan 3 componentes básicos:

• Un Service Worker
• Un archivo de manifesto
• Y que la aplicación sea servida en un contexto seguro (https)

En este post, trato de explicar porque cada uno de estos elementos es importante para que sus aplicaciones web sean consideradas “progresivas”

Service Workers

Los service workers son una tecnología disponible en los navegadores modernos que permite controlar las solicitudes de red. Los service workers hacen posible almacenar en caché los activos y controlar lo que sucede cuando no hay acceso a la red o cuando el acceso es muy lento. En el caso de las aplicaciones web, los activos para el shell de la aplicación se pueden almacenar en caché y luego estar siempre disponibles cuando están fuera de línea o con conectividad limitada.

¿Como registrar un service worker?

El primer paso para obtener un service worker es registrarlo.

A continuación, propongo un ejemplo de como podríamos registrar un service worker. Hay que notar que debemos verificar primero si esta tecnología esta disponible en el navegador que esta ejecutando la aplicación:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js').then(function(registro) {
    console.log('ServiceWorker registrado exitosamente!');
  }).catch(function(err) {
    console.log('El registro del ServiceWorker falló: ', err);
  });
}

Observe cómo el service worker esta en la carpeta raíz. Esto significa que se incluirá en toda la aplicación web. Si hubiera estado en una subcarpeta, se limitaría a esa subcarpeta de forma predeterminada.

Implementación del service worker

Ahora, para el service worker en sí, puede volverse bastante complejo, y una herramienta como workbox-sw realmente puede ayudar a simplificar el proceso para configurar un service worker. La creación manual de un service worker implica la configuración de detectores de eventos para la instalación, activación y recuperación de eventos, pero workbox-sw se encarga de eso “automagicamente“.

Podemos incluir workbox-sw de dos maneras:

// Utilizando el CDN
<script src="https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-sw.js"></script>

// instalandolo con npm
npm install workbox-sw

Una de las características principales de Workbox son sus módulos de estrategia de enrutamiento y almacenamiento en caché. Le permite escuchar las solicitudes de su página web y determinar si esa solicitud debe almacenarse en caché y cómo debe responderse.

Agreguemos un respaldo de caché a nuestros archivos JavaScript. La forma más sencilla de hacer esto es registrar una ruta con Workbox que coincidirá con cualquier solicitud que tenga una propiedad de destino establecida en ‘script’.

import {registerRoute} from 'workbox-routing';

registerRoute(
  ({request}) => request.destination === 'script',
  /* hace cosas con esa ruta */
);

El código anterior le dice a Workbox que cuando se realiza una solicitud, debería ver si la función devuelve un valor “verdadero” y, si lo hace, hacer algo con esa solicitud. Para esta guía, ese “hacer algo” va a pasar la solicitud a través de una de las estrategias de almacenamiento en caché de Workbox.

Si queremos que nuestros archivos JavaScript provengan de la red siempre que sea posible, pero recurrir a la versión en caché si la red falla, podemos usar la estrategia de “la red primero” para lograrlo.

import {registerRoute} from 'workbox-routing';
import {NetworkFirst} from 'workbox-strategies';

registerRoute(
  ({request}) => request.destination === 'script',
  new NetworkFirst()
);

Workbox proporciona algunas estrategias de almacenamiento en caché que puede utilizar. Por ejemplo, su CSS podría publicarse primero desde la caché y actualizarse en segundo plano o sus imágenes podrían almacenarse en caché y usarse hasta que tengan una semana, después de lo cual deberán actualizarse.

import {registerRoute} from 'workbox-routing';
import {CacheFirst, StaleWhileRevalidate} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';

registerRoute(
  // Cache style resources, i.e. CSS files.
  ({request}) => request.destination === 'style',
  // Use cache but update in the background.
  new StaleWhileRevalidate({
    // Use a custom cache name.
    cacheName: 'css-cache',
  })
);

registerRoute(
  // Cache image files.
  ({request}) => request.destination === 'image',
  // Use the cache if it's available.
  new CacheFirst({
    // Use a custom cache name.
    cacheName: 'image-cache',
    plugins: [
      new ExpirationPlugin({
        // Cache only 20 images.
        maxEntries: 20,
        // Cache for a maximum of a week.
        maxAgeSeconds: 7 * 24 * 60 * 60,
      })
    ],
  })
);

Pueden ustedes encontrar este ejemplo y una documentacion mas completa en la pagina oficial de workbox-sw

El Archivo Manifesto

Un manifiesto de aplicación web es un archivo Json con metadatos sobre su aplicación. El contenido del manifiesto es especialmente importante para permitir que navegadores como Chrome en teléfonos Android presenten una opción para que los visitantes habituales instalen la aplicación web en su pantalla de inicio.

Una vez que tenga su archivo manifest.json, inclúyalo en la sección principal de su aplicación con algo como esto:

<link rel="manifest" href="/ruta/al/manifest.json">

A continuación, se muestra, por ejemplo, el contenido del manifiesto de la aplicación web para este sitio web (si lo tuviera :p):

{
  "name": "ricarogeek.com",
  "short_name": "RicardoGeek's Blog",
  "theme_color": "#036bfc",
  "background_color": "#fcfcfc",
  "display": "browser",
  "Scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "images/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

Conclusión

Entonces al tener en su aplicación un service worker, y un archivo manifesto, y ademas servirla en un contexto seguro, garantiza que los dispositivos que la visiten tomaran como progresiva su aplicación e intentaran habilitar dichas características de beneficio para sus usuarios.