5 ms·

But, does Replicache work for your native targets? Or you are okay with a different data layer for native (sqlite) vs web (boutique data model on top of Indexed

by jitl 1y ago

But, does Replicache work for your native targets? Or you are okay with a different data layer for native (sqlite) vs web (boutique data model on top of IndexedDB). At the start of the article it sounds like the goal is to use the same abstraction across web and mobile native and solutions that bifurcate implementation are unacceptable, but then we end up preferring a solution that's different between web target and native targets. Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed; like SQLite-over-IndexedDB, I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records. The big difference between SQLite-over-IndexedDB and Zero-over-IndexedDB is that Zero is written with sympathy to IndexedDB's performance characteristics, whereas SQLite is written with sympathy to conventional filesystem performance. On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong.

isaachinman 1y ago
Yes, Replicache works beautifully on our mobile/native targets. The constructor allows you to pass in any arbitrary KVStore provider, and we happen to use op-sqlite as its performance is exceptional. There is no "different data layer" per se, just a different storage mechanism. Replicache also holds a mem cache that is limited to ~50MB if I recall. Our use case is extremely data-heavy, so we might end up never migrating to Zero – who knows. Perhaps I misunderstood your question, let me know if I can clarify further.
- jitl 1y ago
  Ah, I understood "native application in some targets" to mean you're writing application code in languages other than JavaScript/TypeScript; not that sometimes you're React Native and sometimes you're Web/DOM but you're always TypeScript. Notion always* has a webview component, even in native apps, but we also have a substantial amount of "true native" Swift/Kotlin. We can't use Replicache/Zero today because our native code and our webview share the SQLite database and both need to be able to read and write the data there; if we use Replicache that would make our persisted data opaque bytes to Swift/Kotlin. *There's many screens of the Android/iOS app that are entirely native but the editor will probably remain a webview for a while yet.
  - isaachinman 1y ago
    Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.
aboodman 1y ago
Hi replicache/zero guy here > Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed Replicache exposes only a kv interface. Zero does expose a SQL-like interface. > I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records. The pages are JSON values not binary encoded, but that's an impl detail. At a big picture, you're right that both Replicache and Zero aggregate many values into pages that are stored in IDB (or SQLite in React Native). > On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong. Replicache and Zero are a bit different here. Replicache keeps only up to 64MB in memory. It uses an LRU cache to manage this. The rest is paged in and out of IDB. This ended up being a really big perf cliff because bigger applications would thrash against this limit. In Zero, we just keep the entire client datastore in memory. Basically we use IDB/SQLite as a backup/restore target. We don't page in and out of it. This might sound worse, but the difference is Zero's query-driven sync. Queries automatically fallback to the server and sync. So the whole model is different. You don't sync everything, you just sync what you need. From some upcoming docs: https://i.imgur.com/y91qFrx.png https://i.imgur.com/y91qFrx.png
- jitl 1y ago
  Notion screenshot ;)
  - aboodman 1y ago
    Big fan!
- local_surfer 1y ago
  I really like Zero’s approach: it feels very much like Triplit, including many of its features like query-based smart caching. However, what holds me back from using it is that, unlike Triplit, Zero currently lacks support for offline modifications, which must be a major obstacle for a truly local‑first library.

by jitl 1y ago

isaachinman 1y ago

Yes, Replicache works beautifully on our mobile/native targets. The constructor allows you to pass in any arbitrary KVStore provider, and we happen to use op-sqlite as its performance is exceptional. There is no "different data layer" per se, just a different storage mechanism. Replicache also holds a mem cache that is limited to ~50MB if I recall. Our use case is extremely data-heavy, so we might end up never migrating to Zero – who knows. Perhaps I misunderstood your question, let me know if I can clarify further.

jitl 1y ago
Ah, I understood "native application in some targets" to mean you're writing application code in languages other than JavaScript/TypeScript; not that sometimes you're React Native and sometimes you're Web/DOM but you're always TypeScript. Notion always* has a webview component, even in native apps, but we also have a substantial amount of "true native" Swift/Kotlin. We can't use Replicache/Zero today because our native code and our webview share the SQLite database and both need to be able to read and write the data there; if we use Replicache that would make our persisted data opaque bytes to Swift/Kotlin. *There's many screens of the Android/iOS app that are entirely native but the editor will probably remain a webview for a while yet.
- isaachinman 1y ago
  Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.

aboodman 1y ago

Hi replicache/zero guy here > Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed Replicache exposes only a kv interface. Zero does expose a SQL-like interface. > I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records. The pages are JSON values not binary encoded, but that's an impl detail. At a big picture, you're right that both Replicache and Zero aggregate many values into pages that are stored in IDB (or SQLite in React Native). > On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong. Replicache and Zero are a bit different here. Replicache keeps only up to 64MB in memory. It uses an LRU cache to manage this. The rest is paged in and out of IDB. This ended up being a really big perf cliff because bigger applications would thrash against this limit. In Zero, we just keep the entire client datastore in memory. Basically we use IDB/SQLite as a backup/restore target. We don't page in and out of it. This might sound worse, but the difference is Zero's query-driven sync. Queries automatically fallback to the server and sync. So the whole model is different. You don't sync everything, you just sync what you need. From some upcoming docs: https://i.imgur.com/y91qFrx.png https://i.imgur.com/y91qFrx.png

jitl 1y ago
Notion screenshot ;)
- aboodman 1y ago
  Big fan!
local_surfer 1y ago
I really like Zero’s approach: it feels very much like Triplit, including many of its features like query-based smart caching. However, what holds me back from using it is that, unlike Triplit, Zero currently lacks support for offline modifications, which must be a major obstacle for a truly local‑first library.