Moebius
Progressive web applications
Dan Zajdband (@impronunciable)
Slide 2
Slide 2 text
Quién soy
● Knight-Mozilla fellow (o Nait Morcilla fellow según @alevizio)
● Coral Project (Mozilla / New York Times / Washington Post)
● Herramientas para medios y experimentos con WebVR
Slide 3
Slide 3 text
Moebius (1966)
“Un topólogo investiga la
misteriosa desaparición de un
tren subterráneo junto a sus 30
pasajeros.”
- IMDB
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
El/la Zombie del subte
● Está usando un teléfono
● Intenta navegar con Firefox
● Tiene algo de señal pero cuando entra a un sitio solo ve la barra de carga y una página en
blanco
● Cree que las página son lentas porque se queda cargando. Si ve la página advirtiendo
que está offline culpa a Movistar
Slide 6
Slide 6 text
Pensemos en el usuario. Siempre.
● Qué problema queremos resolverle?
● Qué le falta?
● Cómo podemos ayudarlo a que complete sus tareas?
● Hasta qué punto está bloqueado por sus limitaciones?
Slide 7
Slide 7 text
La respuesta a (casi) todo
PROGRESSIVE ENHANCEMENT
Slide 8
Slide 8 text
Progressive enhancement 101
Slide 9
Slide 9 text
Progressive Web Applications
Conjunto de tecnologías “abiertas” que intentan resolver problemas intrínsecos de la
plataforma web para competir en el mundo móvil.
Dan Zajdband - Poeta
Slide 10
Slide 10 text
Progressive Web Applications
El foco está puesto en:
● Networking
● Lifecycle
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
PWA y Progressive enhancement
Para utilizar estas tecnologías los navegadores tienen que poder:
● Interpretar un manifest.json
● Instanciar un service worker
● https -> (letsencrypt FTW!)
Si el chequeo nos dice que no se puede simplemente no enriquecemos
nuestros sitios
Registrando un service worker: La entrada a Narnia
// Progressive Enhancement: Si podemos usar esta tecnología la aprovechamos, sino
seguimos con la nuestra
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
}
Slide 15
Slide 15 text
Features asociadas a PWAs
● Offline y caches
● Home screen icon + splash screen
● Push notifications
● Background sync + Background jobs
Slide 16
Slide 16 text
Gratarola
Si registramos un manifest y
un service worker somos
candidatos a:
● Install banner
● “Standalone mode”
● Splash screen
Slide 17
Slide 17 text
Gratarola
Slide 18
Slide 18 text
Service worker
Es un script que corre en background y que tiene acceso a ciertas APIs que nuestros scripts
comunes no. De hecho pueden seguir corriendo cuando nos vamos del sitio.
El flujo está muy basado en el uso de Promises. Si todavía no sabes que sos, es buen momento
para aprenderlo.
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
Algunos usos de service workers
● Offline fallback de recursos
● Cache de layouts y recursos estáticos
● Fake APIs para testing
● Push notifications
● Background sync
● Analytics super posta
Slide 21
Slide 21 text
Ciclo de vida de un service worker
● Instalación: Cache de recursos
● Activación: Limpiar caches viejos
● Fetch: Decidimos que hacer con cada request de un recurso
Slide 22
Slide 22 text
La vida secreta del service worker
self.addEventListener('install', function(event) { /* ... */ });
self.addEventListener('activate', function(event) { /* ... */ });
self.addEventListener('fetch', function(event) { /* ... */ });
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
Network y caches
● Nuestro service worker tiene acceso a la CACHE API que nos permite crear caches para
almacenar recursos.
● También se emite un evento en el service worker por cada request en nuestro sitio
(navegación, js, css, xhr, etc...).
● Podemos frenar un pedido a la red y devolver información cacheada, mockeada o ir
incluso seguir a la red y cachear la respuesta para el futuro.
Slide 25
Slide 25 text
App Shell model
● Es un esquema donde el layout se cachea (header, footer, sidebar) y se “rellena” con la
información que se modifica
● Es muy simple hacer una aplicación que cargue instantáneamente (del cache) y se
completa con datos que pueden venir de la red o de otro cache
● Es muy importante contar con `blank states` (siempre lo es pero especialmente en este
caso)
● Este no es un estándar sino una recomendación de gugel
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Background sync
● El service worker recibe un “ping” con un nombre cuando la app tiene una conexión
estable
● Intentamos sincronizar la información que produjo el usuario “offline” con el estado
general de nuestros servidores y le hacemos saber al sw si la sync se hizo correctamente
● Si no fue correcta la sincronización se intentará nuevamente más tarde
● Otra vez, progressive enhancement. Tenemos que chequear si está disponible y actuar en
consecuencia. Si no seguimos con la nuestra
● Límites en el proceso de sync
● Pensar nuestro flujo de datos en términos de sync puede ser más díficil al comienzo pero
es útil también para otros esquemas como real-time y múltiples clientes
Background sync - PouchDB
“PouchDB is an open-source JavaScript database inspired by Apache CouchDB
that is designed to run well within the browser.
PouchDB was created to help web developers build applications that work as well
offline as they do online.”
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
Push Notifications
● Chequear primero si están disponibles
● Tenemos que pedirle permiso al usuario
● Involucrados con los browser vendors (por ejemplo chrome requiere registrar
la app)
● Funcionan como las push notifications mobile nativas