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

Challenges on Offline First Web App in Javascript

Challenges on Offline First Web App in Javascript

Presented on monthly meetup BandungJS

Here we share what is Offline First in terms, historical and technological concerns.
We faced differents concern when develop offline first app against classic online only app.
In the end we extend PouchDB+CouchDB stack to accommodate web app development easily

Ahmad Anshorimuslim Syuhada

February 26, 2019
Tweet

More Decks by Ahmad Anshorimuslim Syuhada

Other Decks in Programming

Transcript

  1. Let’s Talk About Offline First ... With or Without Internet

    Offline First !== PWA Offline First Web?
  2. Let’s Talk About Offline First ... 1. Offline is not

    an error, it’s a state 2. Intermittent Coverage 3. Web App is an “App” 4. Because it’s fun to develop Why should work offline?
  3. Let’s Talk About Offline First ... 1. It’s easier to

    develop offline to online rather than vice versa *)to be continued Why should offline-first?
  4. Let’s Talk About How We Got There ... Internal Research

    and Tools Inspired by Trello (mobile app) Indonesia Coverage are Sucks (IoT) https://tech.trello.com/sync -architecture/ https://tech.trello.com/synci ng-changes
  5. Let’s Talk About The Others Browser → Request HTML, js,

    css, etc → Render → Eval/run JS → Request data → Render
  6. Let’s Talk About The Others Browser → load cached HTML,

    js, css, etc → Render → Eval/run JS → load cached data → Render and manage assets/data update
  7. Keywords Anatomy 1. Serve assets from local first then remote

    2. Serve data from local first then remote 3. Save data to local first then remote Offline First Offline Data Data Example: - user/auth data - datatable/main list - dropdown options - Metadata - Anything ... Offline Assets Assets Example: - HTML - JS - CSS - Images - Fonts View Resources Concern
  8. How To What is Offline Data Data Availability even it’s

    offline Stored in browser, from server Conditional Lifetime Offline Data?
  9. Story #1 > Where to stored? Definitely not memory. Persistent

    storage i.e localStorage or indexedDB > Size Limitation? localStorage (~5 MB) much more limited than indexedDB (up to 50 MB). Special cases for mobile browsers (~5 MB) > Which one should be stored? Depends on what’s your app
  10. Story #1 Offline First - Concern on caching strategy -

    Concern on storage options Online Only - Relatively no concern on storage size limitation - Relatively no concern on caching data strategy VS
  11. Story #2 > When to fetch data? Depends on: RealTime,

    WatchChanges, UserTriggered, Scheduled Only when connection exist > How to manage fetched data? Depends on your needs to show data and how your UX handle data fetching > What about non-offline data? Depends on your UX and coding implementation
  12. Story #2 Offline First - Concern on merging offline and

    online data fetch - Concern on fetching all data (?) Online Only - Relatively simple on demand by page - Relatively simple to handle data fetching strategy VS
  13. Story #3 > What if there’s an update remotely? Don’t

    purge data and re-download > What if there’s an update partially somewhere? Please be prepare for conflict resolution > Conflict Resolution? Similar with GIT, choose your strategy to merge
  14. Story #3 Offline First - Concern on race condition -

    Concern on data merging Online Only - Relatively no concern on data migration/merge - Relatively no race condition update VS
  15. Story #4 > Can we use redux and redux-persist? Need

    to manage localDB sync to redux state. > Can we not use redux and redux-persist? Make sure [re]-render reactively against localDB > What about memory consumption on component load? Make sure localDB could handle smart rendering on which data to load
  16. Story #4 Offline First - Concern on selective load -

    Even doesn’t need redux Online Only - Relatively easy to handle selective load (from server) - Even doesn’t need redux VS
  17. Firebase / Firestore > Strong Points Obvious choice. Backend as

    a Service. React Native Ready > Limitations • Pay as you scale • Limited query capabilities • Sync features are still experimental/unstable, does not support multi-tab, only works on some browsers
  18. CouchDB (server) + PouchDB (client) > Strong Points Distributed Databases.

    Couch Replication Protocol > Limitations • Lots of things to integrate with React • Non-relational, so no join • Still questionable for React Native
  19. Pouchy (Web + RN) > Strong Points Store Interface Handling.

    Extending PouchDB+CouchDB (local & remote ready) > Limitations • Still WIP. Some features/bugs are not implemented/identified yet • Same limitations as [C|P]ouchDB solution > Improvements PouchStore & React Native SQLite Adapter Plugin
  20. CONCLUSION > Offline First to Online is an MVVM pattern

    > Do not use Redux for Offline First > Troublesome on cache invalidation and pagination > Must try Pouch! Even for local data - indexedDB (bigger storage) - Multitab Watch Changes. Better Than Firebase/Firestore > Do Not Create Your Own Sync Mechanism - Use existing protocol if any