Closed beorn closed 4 months ago
Ok, I'll resubmit as part of a new PR rebased on the latest master in a few days.
I had a few questions:
How to see the separation between 'core' and 'demo' stuff - currently there's a ./bin/auth-server-example.js
that is the same as the ./demos/auth-express/server.js
. Should this all be in demo?
Perhaps it would make sense to make a monorepo with each of the services as packages, and some of them being demos? E.g., (also trying to make names a bit longer/expressive - but I see it'd be nice to keep them short too):
workspaces: ["apps/*", "packages/*"]
# core, and perhaps published as npm packages:
apps/yr-sync (server)
apps/yr-compactor (worker)
packages/yr-utils
# not core:
apps/ex-yr-auth-server
apps/ex-yr-backup-server
apps/ex-demo-codemirror
apps/ex-demo-blocksuite
The parts that need to be customizable in the core services could be made customizable through hooks/callbacks/configs.
There seems to be several ways to provide storage for yjs docs, which is good but also a bit confusing:
AbstractStorage
in server.jsIt would perhaps be useful to map out what the generalized storage APIs need to be, and to provide an API to implement to - do we need one for connecting into ydocs directly and one for the functionality that y-redis requires?
The bin/auth-server-example.js
and the rest of the project use uws
for handling HTTP & websocket connections, which I chose for performance reasons. However, I probably wouldn't recommend it to "normal" users at this time, as there is basically no ecosystem around uws (for developing a rest backend, or static file server).
The ./demos/auth-express/server.js
server is built using express, which has much more traction, but is definitely not the "best" technology IMHO.
I want to fill the demos
repository with different implementations of the auth server that users can use to get started. The tests use bin/auth-server-example.js
- which is why it is part of the "main project".
Perhaps it would make sense to make a monorepo with each of the services as packages, and some of them being demos? E.g., (also trying to make names a bit longer/expressive - but I see it'd be nice to keep them short too):
Maybe eventually. For now, this should be fine. I use the same structure in all my projects and I like to keep it simple. There are definitely different flavors of simple. At least this approach is consistent with my other projects.
It would perhaps be useful to map out what the generalized storage APIs need to be, and to provide an API to implement to - do we need one for connecting into ydocs directly and one for the functionality that y-redis requires?
The advantage of y-redis over other implementations is that it doesn't keep the Yjs document in-memory. Hence, you can't use the other providers in y-redis.
If you want to use y-redis, you should definitely implement AbstractStorage
. It's pretty easy, but we are still missing documentation.
You can use any other persistence provider on the client.
Provide a compose.yml for the entire stack: