Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PWA in Practive

PWA in Practive

- Why we create PWA's instead of Apps
- What Problems we had with different Browser Support, bad connectivity, etc
- How we implement "offline first" in the most cases

Avatar for Frank Jogeleit

Frank Jogeleit

January 16, 2020
Tweet

More Decks by Frank Jogeleit

Other Decks in Programming

Transcript

  1. Who am I Frank Jogeleit @move:elevator GmbH
 Backend Engineer GitHub:

    https://github.com/fjogeleit
 Twitter: @FrankJogeleit
  2. Agenda • Kinds of PWA • Personal PWA Projects •

    The good • The bad • The ugly • Learnings This talk is about …
  3. The understanding of PWA’s There are many different types, requirements

    and implementations of Progressive Web Apps • Content based communication Apps like Twitter concentrate on performance und features like Web Share. Offline first is not a really requirement and so you can’t really use it without an active connection • Tools with a focused functionality have no need for a constant connection and can offline first without any downfalls like https://squoosh.app It depends …
  4. The understanding of PWA’s The most projects I know are

    in between. It depends on functionality and sometimes on a specific feature. • When we decide to go with an PWA? • Device Support (iOS, Android, Desktop, Browser?) • User Environment (stable connectivity) • Featureset / Applikation / Context • Deadlines / Timeline / Developers • Deployments / Updates It depends …
  5. What we have made as PWA • Digitale Leader recording

    with dynamic surveys • Appointment Management • Information material: PDF, Images, Video • Multimedia Notes: Audio, Text, Drawings, Images • Teamchat • Statistical Evaluation • Follow Up tools Speedlead
  6. Speedlead • Easy Setup per Customer • Wide device and

    browser support • Core features have complete offline support • create / update / delete reports and notes • open information material • Update is an simple website deployment without additional user actions • Customizable layout The good parts
  7. Speedlead • Speedlead development starts in early 2017, at this

    time there was no ServiceWorker support for Safari • No cache and fetch API for offline support • Not installable on iOS • No Camera / Audio access on installed iOS Versions • No background sync API The bad parts
  8. Speedlead • Complex implementation for Safari Browser support • Offline

    support with RxJS middleware to execute different actions on request failures • Persist failed requests for a later synchronization • Switch in offline mode by request timeouts • Persist files in indexedDB for offline access • Retry logic by expired authorization • LocalStorage as simple persistent redux solution The ugly parts
  9. Speedlead • windows.onLine API works different for Safari, it also

    return true if you are in a network (LAN) without Internet connection. So wie also use requests timeouts as indicator for offline mode • We replaced the indexedDB storage for files with the cache API after Safari also started to support it. • indexedDB loads the complete resource before it returns the file, so it can block your UI with large files • Cache API streams responses which leads to a better performance Learnings