First of all, I’m very excited to work with Y.js. Great project.
Some context: our ‘PubSub’ backend is written in Go. Frontend React/JS. Clients connect to the server using WebSockets. This is also handling the authentication. However, we would like to start using Y.js CRDTs in our app without porting all of Y.js to Go (for now). So the server would not be able to load the Y.doc.
It looks like we have these options:
- Run Y.js in a new node instance for operating on Y.doc structures, persistence etc. Make our backend communicate with this.
- Y.js only on clients, the server would only do broadcasting of messages to clients. Almost like P2P but with a central authority? Server does not need to understand Y.js protocol, and would only handle broadcasting of messages.
- Like 2) but we could we persist all update messages (e.g. in Redis)? I’m sure this has downsides (no compression!), but it might work?
I would love to get started with option 2), because it means we can keep our current stack and don’t need to operate a new server. I’ve looked at
y-websocket and prepared a new version of it that would connect with our existing Go backend.
A few questions remaining: what would the broadcasting logic look like to make option 2 work? How would we initialize the document state if the server cannot load a Y.doc in memory? For new clients, should we request the document from other clients by “signalling” them with a special message, or do we store each update (as data blobs) in the server and “replay” each of the update events? Trying to wrap my head around the limitations of these approaches.