erdtool / yjs-scalable-ws-backend Goto Github PK

Hi, Thank you for your good example of yjs-scalable-ws-backed.
Your code help me to understand how yjs provider work.

I have a question about this part
const persistedUpdates = await getUpdates(doc);
const dbYDoc = new Y.Doc();
dbYDoc.transact(() => {
for (const u of persistedUpdates) {
Y.applyUpdate(dbYDoc, u.update);
}
});
Y.applyUpdate(doc, Y.encodeStateAsUpdate(dbYDoc));

Why just directly update doc like this?
doc.transact(() => for (const u of persistedUpdates) {
Y.applyUpdate(dbYDoc, u.update);
})
I could't guess the reason why make new yjsDocument, apply update and encode new yjsUpdate for apply already exist document.

Hi @kapv89

many thanks for your project. I would love to try it out myself. Before can you tell me whether the awareness issue you raised here, is still a problem?

If not, could you tell me how I could deploy it in k8s. For instance:

• Which prerequisites regarding redis or any other cloud components are necessary?
• Should Redis be a service within k8s or should it be an external one?
• Which environment variables have to be set?
• Can I scale it with a horizontal pod autoscaler?
• Can I also persist documents to other storage like s3 or does it have to be Postgresql?
• Can I somehow allow only specific users to read resp. write a document or block them completely?

It would be great if you could help me with these questions. 😀

@kapv89 I did some load testing for a single instance of the ws-backend, where I have tested the operation in 2 cases:

• average number of calls(5) to different documents(5) - first peak on the graphs
• a large number of connections(35) to one document - the second peak in the graphs

I used a document of 24618 characters, so a large number of messages that need to be exchanged between these sockets.

I am a little concerned:

• Why does the load go so heavily up if we all use the very same document? In my opinion the load should be very low, because there is just one state … for everyone.
• Also, the vCPU is above 0.6 and memory increase 300 MB for just 35 users ons just one document … which is quite a lot.

A small calculation makes it hard to understand for me: 25 k characters is around 25 kb, so a really small document.
Hence, 35 Users * 25 kb = small load, yet we see such a dramatic jump in memory.

Hence, is there some way to do it more efficiently? 🙂

Hi @kapv89, first of all great implementation it helps in making yjs stateless.

I have few questions and findings which I think we can discuss here:

1. I implemented the same redis implementation as in master but I see the awareness handler will cause an infinite loop cause it publishes its awareness in queue and the subscriber listens and applies the update (this update will again have awareness loop)
   check lines
   https://github.com/kapv89/yjs-scalable-ws-backend/blob/main/src/setupWSConnection.ts#L139
   https://github.com/kapv89/yjs-scalable-ws-backend/blob/main/src/setupWSConnection.ts#L296
   I think for update handler also a loop can form which will raise concern

2. The check to publish the update in queue is to check the connection type to be of websocket and if its from the same server instance where it is going to be published
   https://github.com/kapv89/yjs-scalable-ws-backend/blob/main/src/setupWSConnection.ts#L228

   Lets say if I have my service running behind loadbalancer, then in that case no connection will have origin as a valid check and hence it can fail. Can you share more on this as in what cases the check will work

Hi! Nice project!

i'm using and testing it
i saw one TODO in messageListener method to do authentication.

It is about the websocketprovider room password? Or something else?

I'm testing now about scale the pods, why is using PostgresQL? Its possible use MongoDB what you think about?

PS: i can help with some code too

This looks great. However, I don't see any way of pruning the database, so as clients create and edit docs, the persistence element will store an increasing amount of data in the attached database, with no option to ever prune it. Potentially the volume of data could become enormous (this is also true of all the y-websocket variations I have seen). This would be a problem if the code was used in a production environment with large numbers of users performing large numbers of edits.

What should be discarded and when will depend on the use case, but if I have understood this right, it wouldn't be possible to discard data using this backend as currently implemented.

Thanks for a good implementation!

It seems that awareness is not synced across servers, I don't know if it's an issue or not -- but might as well track it here in case you ever want to pick it up again!

Can reproduce this by simply spawning 2 servers, connecting to both, and listening to awareness.

hi there, as a follow up on my work with yjs websocket lib I have referred this implementation.

I have observed that my update buffer in handler consists of unexpected tokens
{�ӓ�s{"name":"Shivam","color":"rgba(224, 17, 117, 1)","alphaColor":"rgba(224, 17, 117, 0.2)","anchor":null,"focus":null}

    at Object.create (/code/node_modules/lib0/dist/error-8582d695.cjs:14:21)
    at Object.<anonymous> (/code/node_modules/lib0/dist/buffer-c2f560d5.cjs:927:41)
    at Module._compile (node:internal/modules/cjs/loader:1191:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1245:10)
    at Module.load (node:internal/modules/cjs/loader:1069:32)
    at Function.Module._load (node:internal/modules/cjs/loader:904:12)
    at Module.require (node:internal/modules/cjs/loader:1093:19)
    at require (node:internal/modules/cjs/helpers:108:18)
    at Object.<anonymous> (/code/node_modules/lib0/dist/encoding.cjs:5:16)
    at Module._compile (node:internal/modules/cjs/loader:1191:14)

Also I have observed this happens when this line is called: https://github.com/kapv89/yjs-scalable-ws-backend/blob/main/src/setupWSConnection.ts#L139

My thoughts, would be as I am testing on local my published content is directly subsribed and some OOM or buffer noise is there.

There is the function saveDocUpdateInRedis in the branch external_api_persistence.

However, it is not used anywhere. Why is that?

Also, in that function is there a way to crunch together all these updates (like you did) and to replace all those updates instead of just pretending it?