Arquitectura de una PWA
Componentes de las Aplicaciones Web Progresivas
Aplicación Web
Comenzar a crear una aplicación web es tan sencillo como definir un archivo HTML y montarlo en un servidor, por ejemplo, mediante serve. Nuestra página principal tiene varios elementos que permitirán tratarla como una Aplicación Web. Veamos el cuerpo de un documento HTML estándar generalmente nombrado como index.html.
Revisemos algunos de los elementos más importantes.
- Etiqueta DOCTYPE — Especifica una aplicación HTML5.
- Etiqueta HTML — Contiene a las etiquetas principales <head> y <body>
- Etiqueta HEAD — Contiene las definiciones de la aplicación, como el título, recursos y metadatos.
- Etiquetas META — Definen metadatos especiales que serán usados a modo de configuración, por ejemplo, el conjunto de caracteres UTF-8, la compatibilidad con Internet Explorer, la escala inicial y el ancho del dispositivo, entre otros.
- Etiqueta TITLE — Define el título usado por la aplicación, generalmente el título de la pantalla mostrada actualmente.
- Etiqueta BODY — Contiene las etiquetas de la interfaz que están siendo usadas para construir todo el diseño visual que será mostrado al usuario. Aquí también se definen las etiquetas SCRIPT, generalmente al final del documento.
Archivo de Manifiesto
Para poder transformar una aplicación web en una Aplicación Web Progresiva, debemos definir un archivo llamado “El manifiesto de la aplicación”, el cuál en términos prácticos es un archivo JSON que define el nombre de la aplicación, la ubicación de los íconos que serán utilizados en diferentes resoluciones, la URL inicial, el color de fondo por defecto, entre otras configuraciones. Estas opciones le permitirán a la plataforma o dispositivo, saber cómo se llamará y comportará nuestra aplicación si fuera instalada. Veamos un archivo estándar del manifiesto, generalmente llamado manifest.json o site.webmanifest ambos son comunes como nombres del archivo de manifiesto, aunque se podría llamar de cualquier forma.
Revisemos algunas de las partes más importantes del manifiesto.
- Atributos name, short_name y description — Establecen el nombre de la aplicación, su nombre corto y la descripción que serán usados para instalarle en la pantalla de inicio. Se usa el nombre corto para nombrar a la app debajo de su icono.
- Atributo icons — Define cada icono mediante un arreglo de objetos con los atributos src, sizes y type, representando la ruta al icono, su tamaño en formato ancho por alto y el tipo de imagen (mime-type). Las dimensiones varian según las plataformas, para chrome se suele usar 192x192 para pantallas pequeñas y 512x512 para alta resolución.
- Atributo display — Define el modo en que se mostrará la aplicación, por ejemplo,
fullscreenmostrará la aplicación completa y sin bordes,standalonemostrará una aplicación sin bordes,minimal-uimostrará una aplicación con los elementos mínimos de navegación como la barra de direcciones,browsermostrará la aplicación dentro del navegador como una pestaña o ventana más. - Atributo orientation — Establece el modo de orientación sugerido al iniciar la aplicación como portrait (vertical) o landscape (horizontal). Otras opciones son any, natural, portrait-primary, portrait-secondary, landscape-primary y landscape-secondary.
- Atributos theme_color y background_color — Establecen los colores HTML de la barra cabecera de la aplicación (theme color) y del color de fondo de la aplicación (background color). Este último es muy útil establecerlo para evitar que se vea una pantalla blanca en lo que carga nuestra aplicación, si es que el color de fondo de nuestra aplicación fuera diferente, por ejemplo, de color negro.
- Atributo start_url— Establece la URL que será lanzada cuándo el usuario abra la aplicación, generalmente se usa un token o un query que permita identificar la procedencia, por ejemplo, es común usar
/?from=pwaasí se podrá analizar a los usuarios que han ingresado desde una PWA. - Atributo scope — Este atributo permite limitar la URL base que pertenecerá a la PWA. Por ejemplo,
scope: "/pwa/"limitará el caché y recursos al subdirectorio, las demás rutas serán tratadas como externas.
Service Worker
Para poder establecer que una aplicación es PWA, debemos crear y registrar un Service Worker. Estos son esencialmente archivos de javascript que se ejecutan en segundo plano, por lo que no tienen acceso al objeto window o document. Sólo tienen acceso a un número limitado de recursos, por ejemplo, el caché, los eventos de instalación, las peticiones a recursos web, etc.
El trabajador en servicio, es conceptualmente, un operador de los eventos de instalación y peticiones web, que tiene la responsabilidad de determinar que será retenido en caché y que debería pasar con las peticiones web cuándo no hay conexión a internet.
Un código estándar para un service worker es el siguiente. Este generalmente se nombra como sw.js, service-worker.js o worker.js aunque el nombre es a modo del programador.
Evento de Instalación
El evento de instalación es llamado cuándo el sitio es visitado por primera vez o se encuentra una diferencia en el caché utilizado, lo más común es agregar al caché los archivos que estarán disponibles sin conexión a internet.
Evento de Activación
Este evento es llamado cuándo el service worker es activado. Lo más común es optimizar el caché utilizado, borrando versiones previas a la actual.
Evento de Petición
Este evento se llama cada que el usuario realiza una petición fetch a recursos, desde mandar a llamar al index.html, las imágenes, estilos o scripts. Lo más común es buscar si el recurso ya está en caché y devolverlo inmediatamente o sino intentar procesar la petición real.
Configuración
Finalmente debemos enlazar el archivo manifest.json y el worker.js dentro de nuestra aplicación.
Conclusiones
La arquitectura de las PWA es tan sencillo como recordar dos archivos importantes el manifest.json y el worker.js. Dentro del manifiesto tenemos la información de la aplicación, por ejemplo, el nombre, descripción, ruta de los íconos, el color de fondo, la orientación, etc. Y dentro del worker podemos encontrar tres eventos principales, la instalación (agregar a caché), la activación (quitar del caché) y la petición (buscar en caché / modo offline).
En el siguiente diagrama podemos ver que las aplicaciones por si solas no tienen una estrategia para resolver los recursos que requieren, por ejemplo, si necesitan una imagen, consumir datos de un API, cargar estilos externos, etc. Simplemente consumen en cada momento lo que necesitan y lo bajan de internet, haciendo que la carga sea más pesada. Por otro lado, las aplicaciones web progresivas poseen un patrón de diseño, el cuál mediante el worker, solucionan la mejor estrategia para retener en caché recursos que serán utilizados cuándo no haya conexión a internet o las peticiones fallen en general. También vemos que esto las convierte en aplicaciones que funcionan 100% online y 100% offline.
