The purpose of this post is, on the one hand, to collect all the individual initiatives of creating a Yjs server, and thus make the research easier for everyone.
On the other hand, it has the objective of organizing us as a community so that we create a definitive Yjs backend. The pieces are already there mostly, we just need to put them together.
Here is the summary of my research:
library | Auth | Persistence | Scale | Multi/Sub-documents | Protocol-agnostic | Persons |
---|---|---|---|---|---|---|
y-websocket | NO | PARTIALLY** | NO | NO | NO | @dmonad |
y-websocket-auth (issue) (discuss) | YES | NO | NO | NO | NO | @raine |
yjs-scalable-ws-backend (discuss) | YES* | On every update | YES | NO | NO | @kapv89 |
(1) y-multidoc-websocket (discuss) (2) snippets on discuss, related blog (3) snippets on discuss |
NO | NO | NO | YES | NO | @LeeSanity, @braden, @DAlperin, @nokola |
yjs-server (discuss) | YES | YES | NO (planned) | NO (planned) | NO | @luishdz1010, @douira |
hocuspocus | YES | YES*** | YES | NO (planned) | NO | Âżnot in discuss? |
.* it’s in the external_api_persistence
branch
** You can get basic leveldb persistence without forking by starting the server with YPERSISTENCE=./dbDir
. Also, there is an internal API, but you need to fork the repo. See this, this and this.
**hocuspocus Previously allowed to persist only rocksdb. Now allows any DB.
-
A sixth important feature that could be added, which Kevin has proposed a couple of times (mainly here, also here or here) is that each document or sub-document keeps a last-modified field and then users when they connect sync those documents that are not up to date. Sounds nice.
-
Of course, a prerequisite for the server would be to use the new differential updates API so that it can save changes without bringing the entire document to memory. I’m not sure which of the libraries use this API so I didn’t add it to the table. If anyone has observations to update this or any other information please put it in the comments and I will update this post.
-
A Middleware API for additional server functionality it’s a must too (thanks @raine). If I’m not mistaken, Hocuspocus also has this thing called “Hooks”.
About Hocuspocus: they plan to change the business model, making the project open source, and in return offering optional cloud infrastructure. From what I’ve read, it sounds like they were planning to get that done in the middle of last year, but they’re having some delays getting it done.
In order to make an official open source server a reality, I can think of 2 ways:
- We could create a new repository at Yjs · GitHub, if Kevin is okay with it.
- Sponsor Hocuspocus or collaborate on its code. Based on what I said above, this would speed up your release to open source, as far as I understand…
open debate