Progressive Web Applications

@ BAFrontend (2016)

Transcript

1. Moebius
   Progressive web applications
   Dan Zajdband (@impronunciable)
   

   View Slide

2. 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
   

   View Slide

3. Moebius (1966)
   “Un topólogo investiga la
   misteriosa desaparición de un
   tren subterráneo junto a sus 30
   pasajeros.”
   - IMDB
   

   View Slide

4. View Slide

5. 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
   

   View Slide

6. 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?
   

   View Slide

7. La respuesta a (casi) todo
   PROGRESSIVE ENHANCEMENT
   

   View Slide

8. Progressive enhancement 101
   

   View Slide

9. 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
   

   View Slide

10. Progressive Web Applications
    El foco está puesto en:
    ● Networking
    ● Lifecycle
    

    View Slide

11. View Slide

12. 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
    

    View Slide

13. manifest.json
    {
    "name": "Muddy",
    "short_name": "Muddy",
    "start_url": "/",
    "scope": "/",
    "display": "standalone",
    "background_color": "#D32F2F",
    "icons": [
    {
    "src": "logo.png",
    "sizes": "256x256"
    }
    ]
    }
    

    View Slide

14. 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')
    }
    

    View Slide

15. Features asociadas a PWAs
    ● Offline y caches
    ● Home screen icon + splash screen
    ● Push notifications
    ● Background sync + Background jobs
    

    View Slide

16. Gratarola
    Si registramos un manifest y
    un service worker somos
    candidatos a:
    ● Install banner
    ● “Standalone mode”
    ● Splash screen
    

    View Slide

17. Gratarola
    

    View Slide

18. 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.
    

    View Slide

19. View Slide

20. 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
    

    View Slide

21. 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
    

    View Slide

22. La vida secreta del service worker
    self.addEventListener('install', function(event) { /* ... */ });
    self.addEventListener('activate', function(event) { /* ... */ });
    self.addEventListener('fetch', function(event) { /* ... */ });
    

    View Slide

23. View Slide

24. 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.
    

    View Slide

25. 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
    

    View Slide

26. View Slide

27. 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
    

    View Slide

28. Background sync - WebStorage
    ● LocalStorage
    ● IndexedDB (IDB promise)
    ● WebSQL
    

    View Slide

29. 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.”
    

    View Slide

30. View Slide

31. 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
    

    View Slide

32. Qué está mal?
    localStorage[‘messi’] = ‘gol’;
    

    View Slide

33. Qué está mal?
    try {
    localStorage[‘messi’] = ‘gol’;
    } catch (error) {}
    

    View Slide

34. La posta
    ● Async/Await (js)
    ● Flexbox (css)
    

    View Slide

35. Recursos
    ● https://www.youtube.com/watch?v=cmGr0RszHc8
    ● https://serviceworke.rs/
    ● https://developers.google.com/web/updates/2015/11/app-shell
    ● https://getmango.com/blog/adaptando-la-web-a-plataformas-moviles
    ● http://hood.ie/blog/beyond-progressive-web-apps-part-1.html
    

    View Slide

36. Preguntas?
    ● dan.zajdband@(gmail | nytimes).com
    ● @impronunciable
    ● Zajdband.com
    

    View Slide