Sync app.storage between multiple instances

[rodja]

With Fly.io, Google Cloud Run, Docker Swarm, Kubernetes etc. a NiceGUI app can be deployed to multiple instances which get fed requests by load balancer. In this scenario each instance will create their own .nicegui directory for storage. Depending on where a user requests are placed the storage data created by one instance may not be available to the other.

NiceGUI should allow a simple way to keep multiple instances in sync.

[rodja]

The most popular solution to sync state between multiple instances is Redis. Maybe we could make the storage solution configurable? Then, instead of writing to disk a Redis database can be used as a shared storage across all instances.

[rodja]

We recently introduced a way to sponsor us, so we could spent more time on NiceGUI.

[rodja]

Anyone interested in creating a draft?

[rodja]

Thanks @Smug246. In the meantime we created the possibility to sponsor us via GitHub. If you are still interested, you could coordinate with #1606 (comment) to offer sponsoring to get this done.

[rodja]

This feature is already quite highly voted (add your's if you need it). There was also a discussion on Discord.

If there are not a lot of data, a workaround could be to use the app.storage.browser because the data will be in a session cookie and is thereby available by any instance the user connects to.

[rodja]

That is a very good question. @falkoschindler and me brainstormed a bit a few days ago because the number of storage options seems to explode: type (user, client, tab, general) x content (serializable, non-serializable) x backend (file, redis, ...). One solution would be to not provide default storages in the long run, but give the user the possibility to create their desired storage via class instantiation...

[hany]

I was looking online for a way to configure NiceGUI's storage centrally using something like Redis, and came across this discussion. Would definitely be a plus for any multi-instance configuration.

[juledwar]

Just came across this, I have the same problem where I want to scale out the app servers and have user storage.

I figured I could just mount a shared volume, but then checking out PersistentDict I see that there's no mutex or co-ordinated access at all, each process assumes total control of its backing file.

This is probably a very high priority improvement for anyone looking to do serious deployments at some scale.

I like the idea of the user instantiating their own storage class, but also having some built-in ones (the existing file-based one for simplicity, plus Postgres, Redis etc). I'd be tempted to have a stab at one but I'm nowhere near familiar enough with the code. 😞

[alydersen]

How would be go about to sponsor such an improvement @rodja ? We would be happy to instantiate a storage class if that was an option. Any way of overcoming multiple workers/threads issues for app.storage.user is very interesting to us and we would be willing to put some money behind this.

[rodja]

Thanks for offering your sponsorship for this. We estimate the implementation of a first usable Redis backend for app.storage.user will take several days. Every sponsorship counts but with one to two thousand dollars we could put it on top of the list and hopefully release something this year.

[alydersen]

Thanks @rodja . I've arranged a USD1000 on time sponsorship and a USD25 monthly. Thanks for making this available for us all, guys!

[rodja]

I started implementing the Redis storage in #4074. It's not much yet, but shows the general principle already.

[rodja]

redis storage which syncs between multiple instances (see #4074) has been released with v2.10.0.