I’m trying to set up a non-JS based server for prosemirror collab, based off the collab sample.
Another thing that I’m trying to do at the same time is to replace polling with websockets.
Regarding websockets - am I right thinking that I should sort of combine the “POST” handler with poll when pushing out updates? If so, do I need to push the version out from the server and how should it be used on the client? I got a bit lost trying to convert the sample to ws, maybe someone can share their own?
Regarding non-JS backend:
I see that the server is applying the steps, similarly to the client, which is something that I would not have available if I am not using JS on the backend (lack of good prosemirror ports for other languages).
I’m wondering if it makes sense at all in such case? Is it enough to just track the updates and versions on the backend, without materializing the doc (or just using full doc sent from clients) ?
what I managed to achieve so far is that on a keypress in one client, all state gets replayed on the other client, so after a second keypress, everything is duplicated on the other client (far from ideal :))
The reason I want a diff backend is that I want to reuse a lot of existing backend business logic that I have, receive updates on the server, and call that business logic depending on the contents of the document.
Any tips / pointers on how to proceed with my task would be very helpful!
You are really going to want to have your server able to apply and validate steps, either by running JavaScript (which is not hard to embed in most languages) or by using one of the existing ports of ProseMirror model/transform to other languages.
Can you elaborate why this is essential? I don’t care about saving the entire doc to file on the server like the collab sample is doing.
What would be the other reason for applying the steps on the server ? When is the output of that operation being sent to the clients ? I had a look at the code but am having trouble to find this relationship between client and server, and it seems to be crucial to figure out before starting to implement my own server.
Ok, i thought about it and thought that I can avoid that (suboptimal) by sending the full doc to the server with each update. I know it’s a hack but I since I’m doing a PoC I want to keep the server minimal.
Are there any other reasons ?
What we did for a while (before switching to sending JSdiff patches along with each diff which we eventually replaced with using prosemirror-py on the backend) was to send the entire document to the server every X number of steps. New clients that were connecting to the document would then get the latest full document + the steps that the server had collected since then.
And that worked at the time… However applying the changes on the server is much smoother and requires less sending back and forth of data.
Thank you all for your replies, I got the PoC (backend without storing the doc and conflict resolution) to work, it turned out I made a mistake following the client code before (ie. two transaction applications are needed on the side that makes the edit, not one).