4 ms·
I just scanned through the video, but it seems to focus on persisting client-side changes locally when offline, which only covers one part of the bigger problem
by matharmin 3y ago
I just scanned through the video, but it seems to focus on persisting client-side changes locally when offline, which only covers one part of the bigger problem.
Difficulties quickly come in if you want to:
1. Persist large amounts of data on the client.
2. Keep the data in sync incrementally (too much data to re-download every time).
3. Keep the data up-to-date in realtime (streaming changes).
4. Keep the data consistent, especially across multiple tables / types.
Many "offline" solutions are actually closer to caching rather than offline-first, which introduce all the issues associated with cache invalidation.
Also, if you're just working with a single table, you might get by with just using updated_at timestamps and soft deletes to be able to get incremental changes from the server. Even then you need to be careful with consistency issues, e.g. making sure timestamps are always in order and without duplicates. And if you start adding more tables, the complexity quickly increases.
- mediumsmart 3y agothank you for pointing that out, yes. I just saw the video uses indexedDB (probably suboptimal although mdn says its ok for storing complex data on the client) and also its just for 'bridging' no internet access when doing input on the device. thank you for taking the time to answer, I see a bit clearer now.
- matharmin 3y agoIndexedDB is fine - just use some wrapped that makes it easier to work with. Our current SQLite implementation actually stores the underlying data inside IndexedDB - mostly due to a lack of better options (but that's busy changing with OPFS). The difficult parts are mostly related to keeping the local data in sync with the server, whether that uses SQLite, IndexedDB or some other database.