3 ms·
I have more interest in this: https://electric-sql.com/ https://electric-sql.com/ They are adding a sync-mechanism for Sqlite so local writes can be synced to
by lawik 3y ago
I have more interest in this: https://electric-sql.com/ https://electric-sql.com/
They are adding a sync-mechanism for Sqlite so local writes can be synced to a remote location and on into Postgres and so on. CRDT-based eventual consistency.
So local write latency, eventually consistent sync and the tools for partial sync and user access are the primary areas of development.
Early days but an interesting approach to shipping the db.
- anty 3y agoOh, I implemented something like that for my Android app. It seems to work quite well. I don't have many users yet, though. I replicate the clients Sqlite DB to a central server (over a REST-API) where it is synced with existing data. I use an CRDT, so changes don't get lost and as long as the clocks of all the users devices are accurate, the merges are in the correct order. This enables offline access, but also the use of my app without an account. You can always merge the data later. Multi-device merge is also possible, if you create an account. Especially the multi-device merge was a big headache until I settled for this approach. Since it is a home-grown solution I still have to do some manual stuff that could be abstracted away, like converting datatypes to and from JSON, Kotlin, PHP, MySQL. There's not always an equivalent datatype in those technologies. This approach probably won't work well for big databases that share data between multiple users, though.
- iamwil 3y agoAre there any advantages you noticed as a dev to using this stack? Did you find there were better affordances? Were there challenges and growing pains?