Hacker News Reader

Comment by jimmywetnips | Hacker News Reader

Seems like you have lots of real world mobx experience.

Have you ever read this article, basically saying that every front end state (including mobx) basically ends up being a worse version of a standard database?

https://sqlsync.dev/posts/stop-building-databases/

I ended up finding that article after running into lots of the challenges with mobx State tree. I ended up trying to use watermelondb, a sqlite wrapped for react native, but gave up entirely on offline due to bugs and project abandonment

View on HN

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.

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 :)

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?

Not GP but isn't it like saying that every database ends up being a worse version of a standard filesystem?

Every filesystem ends up being a worse version of writing to the disk by hand with a magnetized needle.

The analogy is more like an easier to implement version of a system(Custom Frontend Data Store) is worse than the standardized system (Database) rather than one system(database) being implemented on top of another system(filesystem).

The database has more features relative to filesystem, so we wouldn't miss the filesystem whereas a powerful indexing system is a feature in database missing in frontend data stores.

Some other examples below(Firefox plugins which are file browsers, FTP clients, C programs informally implementing subset of Common LISP features).

https://en.wikipedia.org/wiki/Inner-platform_effect

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

https://wiki.c2.com/?GreencoddsTenthRuleOfProgramming

I would retort with, stop trying to chuck a SQL database everywhere.

The issue imho is that multiplayer synchronization (like Jazz) should rely on primitives(CRDT or similar) that you really can't hide under abstractions but should be part of the datamodel to allow for custom synchronization protocols for different parts of the datamodel or even exposing synchronization faults to the user.

An analogy would perhaps be how wrongly abstracted systems like CORBA and DCOM lost out (Even if you can run into them in crevices of enterprise systems) to things centered around HTTP calls or simpler message oriented systems like gRPC.

Reply on news.ycombinator.com