Why not redis for persistance of hocuspocus instead of sqlite?

[ludat]

I was updating the deployment to use hocuspocus and I noticed that it's not scalable (it saves the data to disk in sqlite) so having more than one instance causes a lot of conflicts and restarting the process looses all the data.

Why not use the redis extension instead? since we are already using redis I don't think it would be too much of a hussle

[robguthrie]

The data is not supposed to be permanent. It's only to enable sharing data between clients when collab editing is being used - clients use indexdb locally. It's a temporary store for sure.

We've been using it for loomio.com and the server has never passed 10% cpu usage, so have not come close to reaching max capacity of single server.

Redis means it depends on external service that could go down, requires network round trips rather than local disk, needs more config and I'd need to think harder about how to delete records when threads/etc are deleted on Loomio.

This way I can just cycle the process and it starts a new db.

But hey, go ahead and use redis if you like.. I just don't a any valid reason to.

[ludat]

Sorry, I didn't make myself clear, my main issue was about resilience instead of performance. So if the hocuspocus server fails or restarts the sync fails.

Reading the docs for hocuspocus, it says that it uses redis to sync multiple instances so that they all share the same data, so this is only for a high availability instead of performance.

And since we are already using redis it wouldn't mean another dependency, and even the connection info is already available

[robguthrie]

Arr cool. If the server fails, the local indexdb will continue to work, and when the server comes back any collab-edited changes will be merged correctly. So most clients will never notice anyway