[softfalcon]

Yes, I have read and found similar articles to what you've posted!

It is an ongoing exploration for us to find the best way to store/consume reactive state data within our client sites/apps. So far, MobX has given us a lot of leeway since we can create the data store we want for our data.

Going forward, I foresee us switching to something closer to WatermelonDB or maybe even just SQLite with a thin wrapper in React to create observability. I'm not 100% sure where it's going to go, but I agree with you that flexible state management for large platforms evolves fast and the difficulty of creating fast look-ups rapidly approaches "reinventing the DB" client-side.

I've had to build similar on top of SQLite for various other mobile/desktop apps, the problem hasn't really changed, the only difference is we're now using React + JS instead of C++, C#, or Java.

All roads so far have led to SQLite though.

[bhl]

I've done the same with mobx-state-tree, and realized I was essentially building a relational database with cache-ing in JavaScript.

The only thing SQLite is missed, which is important when integrating with React, is incremental view maintenance: how do we maintain as much immutable state on an update as possible to avoid wasteful re-renders?

[svilen_dobrev]

i have built similar thing long time ago, using couchdb as replication-storage mechanism, and it's variants on non-server platforms - touchdb/android/ios <-> pouchdb/js-browser etc , but yes, except serverside, all other platforms still had sqlite underneath.

Long live sqlite :)