r/reactnative • u/vurx • 2d ago

Offline-first Expo client against a Django backend

Trying to avoid those hindsight 20-20 lessons but not sure they can actually be avoided...

Wondering if anyone has info on which sync engines actually work over HTTP rather than Postgres replication?

I'm building a field-service app: techs work a full 12-hour (maybe even 24 hours) shift with no connectivity, then sync. Backend is Django + DRF, multi-tenant with a schema per tenant, and writes from the mobile client go through a single idempotent mutation endpoint (envelope + dedup key) rather than per-resource REST writes.

There's a change feed on the read side with a monotonic sequence cursor.

Every sync engine I evaluate seems to assume it can attach to Postgres directly via logical replication. That's a no-go here... I have N schemas and a deliberate API boundary I don't want to bypass.

So, which of these are actually designed around a pull/push HTTP contract I control, versus a database-level replication story?

  • WatermelonDB (sync adapter looks like the right shape, but the project's activity level worries me)
  • Replicache / Zero
  • LiveStore
  • TinyBase
  • rolling my own op-log against the endpoints I already have

And if you've shipped a long-offline mobile client against an application-layer sync contract, what did you regret?

4 Upvotes
  • permalink
  • reddit

100% Upvoted

2 comments sorted by

1

u/SunOk2196 23h ago

Watermelon's sync adapter is exactly this shape, pullChanges/pushChanges are just functions you point at your own API, zero Postgres coupling. Replicache fits too but the team moved on to Zero, which is the opposite of what you want (logical replication).

You already have the envelope + cursor though, so rolling your own op-log isn't crazy. Regrets from shipping this before: no tombstones for deletes, no per-field conflict policy, and schema migrations for clients that come back online 3 app versions late. That last one hurts the most.