Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

github.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#31

Post by satvikpendem »

quambo wrote: post #25
satvikpendem wrote: post #19

Looks interesting, was looking for something like this as currently for Flutter I use Loro via flutter_rust_bridge as the CRDT data store, but it's not SQL so some things like big queries are annoying. How are you handling CRDTs in a SQL database? I thought those were notoriously hard as relational wasn't built for CRDT style syncing?

That’s kinda the tension I wanted to avoid. I’m not trying to make the whole SQL database a CRDT. CRDTs are opt-in per column. A row can keep normal, queryable fields like project_id, status, and title, while one doc column stores Yjs/yrs bytes. Concurrent edits to that column are merged by the server; normal columns still use versions and explicit conflicts. Flutter uses yrs through the shared Rust core. The trade-o…

Got it. Many things I do need to be queryable though, like for example if I'm making a to-do list app the todos need to be queryable, so not sure your approach solves much for my use cases. For the Flutter side it's not too bad using FRB, I'd say AI takes care of a lot of the details.

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#34

Post by LoganDark »

pettijohn wrote: post #32
jmull wrote: post #21

No mention of conflict resolution? I suspect it's far too naive to be useful for anything real.

https://github.com/syncular/syncular/blob/0ff4fed6b7e538293e...

I'm not sure I would entirely trust a tricky algorithm not written by a real developer. Still, interesting.

(If it is manually written I don't trust the LLM-written docs.)

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#35

Post by elsaicequeen »

Pretty cool.

How do you handle browser storage eviction? I shipped a DuckDB-Wasm in-browser and found that survives reloads isn’t isnt really reliable.

Since pending writes live in the OPFS SQLite database, does the recommended setup request persistent storage or warn the user that an unsynced outbox could disappear if the origin is evicted?

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#36

Post by jmull »

pettijohn wrote: post #32
jmull wrote: post #21

No mention of conflict resolution? I suspect it's far too naive to be useful for anything real.

https://github.com/syncular/syncular/blob/0ff4fed6b7e538293e...

There's not much there.

Trying to guess what's going on from what is there... looks like conflicts are raised on a per row basis, and the app resolves the conflicts.

Per-row is going to make it hard to handle a lot of data models. Maybe there's some way to see the whole transaction, but how? And how can you see the server vs local data? You'll want that for many cases.

It's right to leave it to the app to resolve conflicts -- there is no one-size-fits-all answer to this. But by providing no tools and, seemingly pushing everything through a per-row API, it's going to be essentially impossible for apps to get things right. You'll end up with incoherent data -- data that isn't valid within one node, and nodes different from each other. Generally, not what you want when you implement sync.

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#37

Post by quambo »

elsaicequeen wrote: post #35

Pretty cool. How do you handle browser storage eviction? I shipped a DuckDB-Wasm in-browser and found that survives reloads isn’t isnt really reliable. Since pending writes live in the OPFS SQLite database, does the recommended setup request persistent storage or warn the user that an unsynced outbox could disappear if the origin is evicted?

[flagged]

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#38

Post by quambo »

LoganDark wrote: post #34
pettijohn wrote: post #32

Earlier quoted context omitted.

https://github.com/syncular/syncular/blob/0ff4fed6b7e538293e...

I'm not sure I would entirely trust a tricky algorithm not written by a real developer. Still, interesting. (If it is manually written I don't trust the LLM-written docs.)

[dead]

Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

#39

Post by quambo »

jmull wrote: post #36
pettijohn wrote: post #32

Earlier quoted context omitted.

https://github.com/syncular/syncular/blob/0ff4fed6b7e538293e...

There's not much there. Trying to guess what's going on from what is there... looks like conflicts are raised on a per row basis, and the app resolves the conflicts. Per-row is going to make it hard to handle a lot of data models. Maybe there's some way to see the whole transaction, but how? And how can you see the server vs local data? You'll want that for many cases. It's right to leave it to the app to resolve con…

[dead]
Post reply on HN