rocky musk
Am I really going to have to self-host this because of absurdly low rate limits? I see that there is no difference in rate limits regardless of the plan we're on, so Cloud seems totally unusable.
My users simply need to be able to move boxes around so a move / size change is a database hit. I can rate limit myself in seconds seemingly by just moving them around.
south summit
when you say testing, maybe use a locally self hosted instance, use something like ngrok or cloudflared tunnels to expose the instance to other users.
for move/size change, use something like a debounce logic to update the db.
solemn whale
Assuming you are talking about rate limit for Update Document in DB? The rate limit is 1210 requests a minute, and applies uniquely to IP + Method + URL + User ID. So, if one user hits the rate limit, the rate limit will be unaffected for other users.
Databases aren't the best way to store state of something like this if you are updating it every half a second... There are far better solutions out there for that sort of thing.
balmy kindle
Am I really going to have to self-host this because of absurdly low rate limits?...
Do you can sync the changes every X seconds (for example 1 or 0.5 or 0.3 secconds)?
You can interpolate the movement in order to make it feel like smooth movement for other users if you need to sync it with realtime to other users.
I think that your current approach is basically syncing literally every pixel that changes.
In my opinion doing that with the current database architecture and in this case is probably very resource consuming.
Also, @rocky musk I think that this feature request could be interesting for you as it's implementing a realtime listening system that is probably much more suitable as it's not permanent interaction with the server database (MariaDB) but a sync between clients, achieving lower latency (probably using Redis):
https://github.com/appwrite/appwrite/issues/2418
