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

41–45 of 45 posts

Re: Loro: Reimagine state management with CRDTs

#41

Post by jitl »

vosper wrote: post #31
jitl wrote: post #9

The demo code for Loro looks very easy to use, I love how they infer a CRDT from an example plain JS object. I’ve played with a Zod schema Yjs CRDT translator and found it kinda annoying to maintain. However this looks so easy I worry about apps building with too little thought about long term data modeling. Migrations on CRDTs are challenging, so it’s important to “get it right” at the beginning. I’m curious how thi…

> Migrations on CRDTs are challenging, so it’s important to “get it right” at the beginning. Any tips or dos/don'ts you could share for how to "get it right" at the beginning? I'm hoping to build an application using CRDTs sometime in the future.

I don’t have anything better for you than “be careful” and “prototype a lot”. Adding new fields is fine, changing the meaning or type of existing fields is annoying.

You should try to brainstorm a lot of future feature improvements and ideas you might want in 2 years and consider if your v1 design would block or need a challenging migration to support the hypothetical v100 designing. A classic example is if you need a one-to-one relationship in v1, think about how you’d support that as a one-to-many or many-to-many. It might be better to start with a schema that supports many-to-many to avoid shenanigans down the line.

I linked the Cambria essay below which has a lot of food for thought.

Re: Loro: Reimagine state management with CRDTs

#42

Post by two_handfuls »

aatd86 wrote: post #38
ablob wrote: post #33

Earlier quoted context omitted.

You can implement delete operations by marking fragments as deleted. That way you can still refer to them from a positional perspective, but they will eventually disappear. The exact behavior depends on the implementation, the only requirement is that every "user" reaches the same state eventually. A: delete Line 4@marker B: append to the end of line 4@marker "abcd" could then result in either line 4 with only "abcd"…

I guess my question is of whether the state that is being reached is a legit one in this case. What is the source of truth eventually? I think there must probably be a hierarchy that decides it. It's probably a kind of race condition/byzantine general problem.

These systems are based on the idea is that rather than directly editing the shared document, each program sends a stream of “update objects.” An example would be “create new line $xyz after line $abc.”

These “update objects” can be combined to get the current document state.

They have the property that if two programs receive the same set of uodate objects, regardless of the order they get them in, then they have the same current document state.

They define any state resulting from applying the operations as “legit.” In order for that to feel “legit” to the users you want to very carefully choose your operations and their semantics.

Re: Loro: Reimagine state management with CRDTs

#43

Post by enva2712 »

jitl wrote: post #39
enva2712 wrote: post #37

Earlier quoted context omitted.

I don’t see why migrations on CRDTs would be categorically different from migrations on other data types, though maybe there’s less open source tooling to leverage at the moment. I’ve got some basic code written on automerge to handle them in a side project

It’s more challenging because you need to accept updates in format v1 indefinitely even after you apply the v1->v2 migration, which makes it more like maintaining an API with backwards compatibility than the usual SQL migration pattern. For example, let’s say you start with a last-write-wins CRDT for an object of shape { name: string, bio: string } in v1, and then decide bio should use a convergent rich text data typ…

The lens solution is clever and, I’m glad to see lenses catching on outside the haskell ecosystem

I think the primary issue you raise comes down to whether or not the peers can be verified to be updated before applying the migration op. If this is the case, you can go the standard sql route of deploying a diff adding forward compatibility, applying migration op, deploying diff removing backward compatibility. This is the route I’ve gone since in my case the peers are web browsers so I’ve got a pretty reliable deployment system; though the lens solution is much better since it lifts this requirement

Re: Loro: Reimagine state management with CRDTs

#45

Post by czx111331 »

curtisblaine wrote: post #44

I couldn't find this in the docs, but is it easy / transport agnostic to sync two remote instances through the network? What about saving state on the server (so different devices can sync with each other without having to be online at the same time?)

Yes, it's agnostic to the network layers. The output of doc.exportFrom() is just a binary array.
Post reply on HN