[williamstein]

This is really amazing as is their standalone pglite project, which is a WASM port of Postgres. One surprise for me though is that Electric is a read only replica. In particular, “Electric does read-path sync. It syncs data out-of Postgres, into local apps and services. Electric does not do write-path sync. It doesn't provide (or prescribe) a built-in solution for getting data back into Postgres from local apps and services.” https://electric-sql.com/docs/guides/writes

[aidos]

We hit on exactly the same pattern for our product and it works really well.

We use Hasura as the read engine. That updates a graph of mobx objects that drive the ui. We apply updates directly to those objects so the ui updates immediately. The mutations are posted back to a Python api that applies them to the db.

I’ve looked at Electric because we’ve had to recreate some of what they do to interface with Hasura. At the moment it’s a non-starter because we use pg views to shape the data for the frontend.

[thom]

Have you looked into something like Materialize? That’d give you realtime updates over even materialised views, works to back Hasura etc.

[aidos]

Hadn’t seen that one. Thanks for the heads up. It’s the sort of thing that I could see being useful in a bunch of places. We have a number of hand rolled things to deal with similar issues.

Might not be a perfect fit here because some of the views are session context dependent (but could maybe still be workable).

[mrlase]

Would love to read more about how you have mobx structured here. I have a similar graph of mobx objects for something I’m building but haven’t come up with an ergonomic sync story yet.

[aidos]

Mine is simple but relies on a few cheap tricks (like generating uuids in the frontend and manually linking relationships in an order where replaying on the db is going to work). Happy to walk you through it if you want to message me.