ProseMirror/Yjs (y-webrtc) in a serverless architecture PoC

Show
1

We want to run Prosemirror/yjs in a serverless architecture.

I took the points from the forum to build a PoC. Sharing this here in the hope that others can benefit from this as well:

https://github.com/Collaborne/remirror-yjs-webrtc-demo :slight_smile:

The README describes the questions we aimed to answer with the PoC and the approach that we took.

I’d highly appreciate any feedback on the chosen approach! Does this reflect best practice?

1 Like
2

Thanks for sharing! Very interested in this!

It’s on our list to add this to the tiptap core. On our first (and time intense) attempt, we had problems mapping Y.js positions. Related issue here:

Besides that: I like everything you wrote and it’s similar to what we planned.

3

Is yjs/webrtc + save snapshots the best approach to implement yjs in serverless setup? Does anybody have experience with alternative patterns?

4

I’m noticing that annotations aren’t restored on an undo.

5

is there a way to automatically know how is the “host”? I mean if there are 5 users, who should persist? TIA

6

Yjs is host-less. It doesn’t require a central authority to resolve conflicts. Hence, Yjs can’t help you to elect peers.

7

agree, but then how is everyone “saving” / persist? when using webrtc? if I use awareness sort clientId and peek the first one, that should work? the problem is that there is a timeout of 30 secs right?

8

The network is not reliable. So this method doesn’t elect the same peer reliably.

In general, the “saving” approach seems like an antipattern to me in collaborative environments. If you have a central server to save stuff, you can simply use y-websocket.

If you still want to use y-webrtc and send the document to the server in regular intervals, I recommend to send the Yjs document (instead of your custom JSON encoded document). On the server, you can merge the received Yjs document with the document that you already have in a database and merge them using Y.mergeUpdates([currentState, newState]). The result will be the latest version of the document, even if the client is a bit behind. This approach doesn’t require to elect a peer, every peer can perform a save request.

9

thanks! I agree with your point of view. but the idea of using webrtc and not websockets is to don’t have backend process every single delta/update. I tried to find any stats about that… if I use websockets… imagine there are 10 users working together on a quill document, and let’s say all of them are writing non stop for an hour. how many messages will be used in total in websockets? I thought of using webrtc to avoid websockets costs / backend lambda methods calling costs. thank you!!

10

if I try to do any calculation… I end up with millions of messages per day… is that normal? or too much? re using websockets

11

That’s one message per keystroke… So you might easily end up with up to a few hundred thousand messages per user.