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

Loro: Reimagine state management with CRDTs

loro.dev

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Loro: Reimagine state management with CRDTs

#11

Post by btown »

hugodutka wrote: post #4

We've been using https://github.com/electric-sql/electric for real-time sync for the past month or so and it's been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it's actually faster to ship an application without writing any APIs and…

What kinds of bugs have you run into? Any large-scale corruption of data at rest?

Re: Loro: Reimagine state management with CRDTs

#12

Post by Inviz »

Well it's honestly about time. I've tried to build something like this personally with OTs, but it can be pretty brutal with all the fuzzying and N-way merges. I even chose one of rich editors just because it supports OT (then i learned it's only in commercial version not even available for small-timers).

I like the completeness of the Loro solution: the state, the rich text, the tree. Local-first database approach sounds like a great idea. Wondering how large is the code size overhead for using this though.

Re: Loro: Reimagine state management with CRDTs

#14

Post by hugodutka »

btown wrote: post #11
hugodutka wrote: post #4

We've been using https://github.com/electric-sql/electric for real-time sync for the past month or so and it's been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it's actually faster to ship an application without writing any APIs and…

What kinds of bugs have you run into? Any large-scale corruption of data at rest?

We have run into queries that corrupted the database client-side, but fortunately that doesn't propagate into postgres itself. In that case we had to drop the client-side db and resync from a clean state.

The corruption was also caught by sqlite itself - it threw a "malformed disk image" error and stopped responding to any further queries.

Also bugs around syncing some kinds of data - one bug that's already been fixed was that floats without decimal points would not get synced. https://github.com/electric-sql/electric/issues/506

In general electric's team is very responsive and fixes bugs when we bring them up.

Re: Loro: Reimagine state management with CRDTs

#16

Post by matharmin »

hugodutka wrote: post #4

We've been using https://github.com/electric-sql/electric for real-time sync for the past month or so and it's been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it's actually faster to ship an application without writing any APIs and…

How do you deal with shapes and permissions not being available yet?

Re: Loro: Reimagine state management with CRDTs

#17

Post by hugodutka »

matharmin wrote: post #16
hugodutka wrote: post #4

We've been using https://github.com/electric-sql/electric for real-time sync for the past month or so and it's been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it's actually faster to ship an application without writing any APIs and…

How do you deal with shapes and permissions not being available yet?

There's a workaround - if a table has an "electric_user_id" column then a user with that id (based on their JWT) can only read rows which have the same id. It's basic but it works for us. https://electric-sql.com/docs/reference/roadmap#shapes

Re: Loro: Reimagine state management with CRDTs

#18

Post by singhrac »

This looks really neat. I appreciate that you reference the previous work in this area (by josephg, Ink & Switch, Fugue etc.).

I think the roadmap says that WASM is next as a target, and that makes sense for prioritization. Would you also consider Flutter/Dart as a target, even if at the level of "we checked once that flutter_rust_bridge can call Loro"?

Post reply on HN