Very cool overall but the sync->async change means you can't always use it as a drop-in replacement. I assume it's making network calls in those cases which will take significantly longer that local writes. I wonder if something could be done so that it write the data locally and kicks off something async in the background to sync it up to the backend. Maybe with just a timestamp in case you go offline to handle conflicts (or even way to register a callback if there is a conflict so you can decide how to handle it). I know that all makes this more complicated but I'd be worried about adding waiting for a network call where I currently do localStorage calls.
But still a very cool project, thank you for sharing!
Good question. I like the idea of having a configuration that includes optimistic writes and perhaps even reads from localStorage for projects that have very low latency/unstable network requirements.
That being said, the server is blazingly fast as it leverages Redis and Fastify under the hood. In most of my testing, even on WiFi in SF with a server in Oregon, I would achieve <20ms reads/writes.
Totally fair point and I understand that as-is it’s way simpler than what I proposed. I just know there are places I have to change a whole chain of functions from sync to async to use this (not the end of the world).
I’m tempted to rewrite the backend in lambda+dynamoDB for a completely serverless backend (though for anything serious you’d probably want provisioned lambdas to avoid the cold start).
But still a very cool project, thank you for sharing!