 Hola, me llamo Demián y trabajo en el equipo de ecosistemas web de Google. En esta charla vamos a aprender cómo distintas compañías están utilizando APIs de la web moderna para crear sitios más resilientes y más rápidos. Para los ejemplos, vamos a utilizar Workbox, ya que nuestra forma recomendada de desarrollar sitios que usan service workers, pero cualquiera de estos patrones puede implementarse directamente en JavaScript, sin ningún tipo de componente externo. El primer patrón se llama Experiencias de búsqueda resilientes y puede implementarse en cualquier sitio que ofrezca algún tipo de funcionalidad de búsqueda. Cuando un usuario realiza una búsqueda en la versión web de Google Search para Android y pierde conexión, en lugar de la pantalla estándar de error de conexión, se le presenta una pantalla preguntando si desean suscribirse a notificaciones. Si el usuario acepta el permiso, una vez que la conexión regresa, recibirá una notificación indicando que el resultado de la búsqueda está listo. Clickeando en la notificación, llevará al usuario a la página de resultados. Esta es una buena manera de permitir al usuario completar la tarea, independientemente del estado de la red. El corazón de esta implementación es la API de Background Sync, que permite diferir acciones hasta que el usuario tenga conexión. En Workbox, esto puede implementarse fácilmente. Primero, creamos una estrategia de caching network only para la URL del servicio de búsqueda. Y le pasamos un plugin para encargarse de los escenarios offline. El plugin de Background Sync de Workbox recibe el nombre de una cola como parámetro donde se guardarán las búsquedas fallidas. A continuación, definiremos el callback onSync que será ejecutado cuando la conexión se recupere. Con este código se ejecuta, podemos recorrer la cola de pedidos fallidos y procesarlos, y al finalizar, enviar una notificación con el resultado de la búsqueda. Un detalle importante en la implementación de Google Search es cómo se presenta el permiso de notificaciones. En el momento que se muestra, el usuario entiende el valor del servicio. La notificación, por su parte, contiene información precisa y relevante. Es un buen ejemplo de uso de permisos de notificaciones en la web. Nuestro siguiente patrón es carga adaptativa con Service Workers, que nos permite alcanzar experiencias rápidas con independencia de la red y el dispositivo. Terra es uno de los sitios de noticias más grandes de Brasil. Tiene una gran base de usuarios, accediendo al sitio desde una amplia gama de dispositivos y conexiones. Para proporcionar una experiencia más rápida a todos sus usuarios, Terra ha decidido combinar Service Workers y la API de Network Information para servir imágenes de menor calidad a usuarios con conexiones 2G y 3G. Terra ha decidido llevar a este estrategio un paso más allá. Cuando un usuario accede al sitio bajo conexiones menores a 3G, el Service Worker retorna a las versiones AMP de sus artículos, que son más livianas y funcionan mejor bajo estas condiciones. Para implementar esta funcionalidad en Workbox, primero aplicaremos una estrategia de caching Cache First para las imágenes. Luego pasaremos un plugin de exploración, indicando la cantidad máxima de imágenes a mantener en calle. Finalmente extenderemos esta estrategia con un plugin, al que llamaremos Adaptive Loading Plugin. Dentro del plugin implementamos el método Request Will Fetch, que será llamado justo antes de que se realice el pedido, para que podamos modificarlo. Dentro del método podemos chequear el tipo de conexión y, si es una red lenta, cambiar la URL para solicitar un recurso más liviano. Por ejemplo, una imagen de menor calidad. Finalmente, creamos un nuevo objeto Request, basado en la URL recientemente creada. En estos primeros dos patrones vimos cómo combinar dos funcionalidades de Workbox. Por un lado estrategias de caching, como Network First y Cache First. Por otro lado, utilizamos plugins, un plugin standard como Workbox Background Sync, y uno creado completamente por nosotros, para el caso de la carga adaptativa. Esto demuestra la flexibilidad de Workbox para adaptarse a los distintos casos de uso de una Progressive Web App. En nuestro siguiente patrón, vamos a ver cómo lograr navegaciones instantáneas. Un flujo típico de un usuario en un sitio puede involucrar múltiples pasos, cada uno de los cuales implica un pedido de navegación. Este tipo de pedidos, por ejemplo, de páginas HTML, suelen satisfacerse a través de la red. En estos casos, se utiliza un header Cache Control de Now Cache, para asegurarnos de servir contenido actualizado. Periodo de la red significa que cada navegación puede ser un poco lenta, o al menos no lo suficientemente rápido. Para acelerar estas navegaciones, uno puede utilizar una técnica llamada Prefetching, que nos permite solicitar recursos justo antes de que el usuario los pida. Por ejemplo, Mercado Libre utiliza el tag Link Prefetch, para precargar los siguientes pasos en una lista paginada. Juané Andrew Flowers le pide a su Service Workers traer las páginas de producto más destacados justo antes de que el usuario el quede en ellos. Prefetching comúnmente se implementa con un tag Link Prefetch. El tag le indica al navegador que traiga un recurso con prioridad baja y lo mantenga en calle por 5 minutos. Un buen complemento de esta técnica es combinar este tag con una estrategia de caching del lado del Service Worker. Para ello, con Workbox podemos comenzar definiendo una estrategia de runtime caching para interceptar los pedidos de páginas. Para páginas HTML como páginas de producto, una buena opción es una estrategia Stale While Revalidate, que permite responder rápidamente con el contenido de la calle mientras se realiza un pedido para mantenerla actualizada. El resultado de esto es una navegación prácticamente instantánea. Un último patrón nos permitirá aplicar la técnica AppShell, característica de la Single Page Applications, en una arquitectura web tradicional o lo que se llama Multi Page App. El primer paso es dividir el sitio en partes atómicas, empezando por el encabezado y el pie de la página. Estos archivos parciales se almacenan en calle durante la instalación del Service Worker. De esta manera, el contenido de la página es la única parte que se trae desde la red cuando ocurre una navegación. El ingrediente clave de esta implementación es la utilización de streaming, gracias a lo cual el encabezado puede dibujarse antes de que la respuesta de la página esté completa. Para implementar esta técnica en Workbox, utilizaremos una estrategia de runtime caching para interceptar pedidos a páginas. Luego pasaremos un array de respuestas para cada parte de la página. Para el encabezado y el pie, utilizaremos una estrategia cache-first para intentar responder rápidamente con el contenido de la calle. Para el contenido, utilizaremos una estrategia network-first para buscar esta parte de la página desde la red. Workbox se encargará de unir todas estas respuestas. Gracias al uso de streaming, podrá comenzar a devolver los bytes del encabezado sin tener que esperar que el resto de la respuesta esté lista. El resultado de esto es una experiencia similar al de una single-page app tomando como base una arquitectura web tradicional o multi-page application. En esta charla vimos 4 patrones de Progressive Web Apps para lograr experiencias más rápidas y resilientes en la web. Como complemento, subiremos una serie de artículos a la sección Patrones avanzados de WebDev Barra Drill Eye Award. Espero que hayas disfrutado de esta charla y que puedas experimentar con estos patrones dentro de tu sitio. Muchas gracias.