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

You don't need a CRDT to build a collaborative experience

zknill.io

Post reply on HN
Print view View original

51–60 of 70 posts

Re: You don't need a CRDT to build a collaborative experience

#51

Post by socketcluster »

The no-code serverless platform I built achieves this behind the scenes via a real-time CRUD API: https://saasufy.com/

The key is to perform updates on fields individually. Normally this would not be viable using HTTP due to headers/overheads (too many fields per resource to dedicate an entire HTTP request per-field) but it is viable over WebSockets as each frame is very lightweight and can even be batched. Also, being able to tie together the life of the connection to the subscription is handy to ensure that no real-time updates can be missed.

I built a chat app with authentication + access control with it (you can log in with GitHub at the bottom):

https://saasufy.github.io/chat-app/

Only 120 lines of HTML markup (web components), no custom JS. See GitHub repo here for the 'source': https://github.com/Saasufy/chat-app

Re: You don't need a CRDT to build a collaborative experience

#53

Post by Summerbud »

jitl wrote: post #10

I agree broadly with the article’s position but I think locks are more harmful than helpful. When I was a Quip user (2018) it was super frustrating to get locked out of a paragraph because someone’s cursor idled there. Instead just allow LWW overwrites. If users have contention and your sync & presence is fast, they’ll figure it out pretty quick, and at most lose 1-2 keystrokes, or one drag gesture, or one color pick…

I feel the same in the paragraph. But in some situation it seems rational

Figma still limits you from editing the component if someone is on it. And Figjam did that too. In my mind, this is a good practice in the realm of collaborative design. Because it will be very messy if a single component obeys the last-write-win rule

Re: You don't need a CRDT to build a collaborative experience

#54

Post by SoftTalker »

ivanjermakov wrote: post #21

Conflict-Free Replicated Data Type (CRDT) is a type of data structure that enables concurrent updates across multiple replicas without the need for coordination between them.

Thanks, I was scanning the replies looking for this since the author of TFA didn't. Note for writers: spell out acronyms on first use.

Re: You don't need a CRDT to build a collaborative experience

#55

Post by ccorcos »

jitl wrote: post #10

I agree broadly with the article’s position but I think locks are more harmful than helpful. When I was a Quip user (2018) it was super frustrating to get locked out of a paragraph because someone’s cursor idled there. Instead just allow LWW overwrites. If users have contention and your sync & presence is fast, they’ll figure it out pretty quick, and at most lose 1-2 keystrokes, or one drag gesture, or one color pick…

I agree!

If people clobber each others updates by typing at the same time in the same input, at least they can understand what happened.

That’s much better than not being able to do something because someone left their cursor on something and walked away…

Re: You don't need a CRDT to build a collaborative experience

#56

Post by andyjohnson0 »

Because it doesn't seem to be defined in the article:

CRDT = conflict-free replicated data type [1]

I keep seeing this acronym and mentally parsing it as CRT, at which point I get very confused.

[1] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

Re: You don't need a CRDT to build a collaborative experience

#57

Post by zknill »

speps wrote: post #43

The Wikipedia page for Operational Transformation [1] mentions Differential Synchronization [2] as an alternative, does anyone have any experience with DS? [1] https://en.wikipedia.org/wiki/Operational_transformation [2] https://neil.fraser.name/writing/sync/

When you search for usage of Differential Sync you'll find lots of news reports about it being included as technology in file sync and file backup solutions.

I've not directly worked on it, but I get the impression that it's mostly used in file backup because of how Differential Sync works. In Differential Sync the server and the client both hold two copies of the data/document. One representing their own state, and one representing what they thing the other's state is. Then the differences are computed between those documents and sent to the other.

For any given client, this isn't too onerous. You'd have to hold the client and server copy of the doc. But for a server, serving many clients, you'll end up with a lot of client-specific copies of that document. For N clients, you'd have N+1 copies of the document. It doesn't take too many clients before this becomes a real problem.

So if you're backing up 1 client to 1 server, Differential Sync is fine. But if you're trying to keep tens, hundreds, or thousands of clients in sync then you end up with a lot of client "shadow" copies of the server's document.

Re: You don't need a CRDT to build a collaborative experience

#59

Post by czx111331 »

We are addressing the CRDT downsides mentioned in the article at Loro:

- Ever-growing state. This is no longer an issue. With OT-like CRDTs, you can discard unnecessary historical data at any time. This is theoretically feasible, and we are moving towards this goal. - Complex implementation. The complexity is internal within the package, and it's written in Rust, making it universally applicable. - Opaque state. We aim to expose these internal states through improved DevTools, making them easier to control and observe. This is one of the essential steps in enhancing our DX.

You can visit our blog to learn more: https://www.loro.dev/blog/loro-now-open-source

Re: You don't need a CRDT to build a collaborative experience

#60

Post by Reinmar »

josephg wrote: post #32
lewisjoe wrote: post #12

> everyone’s gonna say “but hey, google docs uses operational transform not CRDTs”.. OK yes, but you are not google. Well, google docs works not because they somehow figured out how to converge OT edits with as much precision as CRDTs do, but simply because they have a central server which orders edits anyway and don't need true leader-less convergence. In fact, I agree not many things don't need a CRDT. CRDTs help w…

Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol. It’s fast and relatively straightforward to code up, and unlike text CRDTs it’s pretty fast by default. I use it as my standard test when trying out a new programming language. It was unexpectedly ugly in go because of go’s lack of enums & unions, and that’s one of the big reasons I never got in to pr…

> Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol.

Just for clarification, while OT for plain-text (linear model) might be simple to implement, OT for typical rich-text editors (like Google Docs) that need to rely on a tree-structured data model is a whole different story: https://ckeditor.com/blog/lessons-learned-from-creating-a-ri....

Post reply on HN