Would something like this be possible?
Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
131–140 of 173 posts
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#132Earlier quoted context omitted.
You are really taking the expression `shameless plug` to another level in this thread, aren't you?
Genuinely excited about this space and it's what I'm focused on full-time so definitely have thoughts to share. I am wary of self-promotion. I do want to contribute things that I feel are relevant to the discussion, since I assume folks would be interested to see different patterns/approaches around local-first/offline-first architecture.
You can only be genuinely excited if you don't need to add a link to your product when talking about it. This one was actually your most interesting reply, I shouldn't have posted about the high amount of mention to your own competitor project here.
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#133How does this deal with schema changes? We have a solution where old clients can store objects that have new fields unknown to the client. Then when the clients updates the data is visible.
Do you have client libraries for mobile? Swift & Kotlin?
Does it support partial sync and fetch when you need an “archived” item? In my experience you only want the “working set” of data on the client. Not everything.
Cool work! CRDTs are the solution to this.
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#134Is there any validation or authorization for changes being merged back into the root database? In a traditional client / server model, the server has an opportunity to validate each request and optionally reject it. The lower level you go with the sync protocol (data changes vs high level requests) the more difficult that becomes. Have you addressed that and, if so, how? What prevents a malicious client from send arb…
The route that we went with for PowerSync (disclosure: co-founder) is to allow to define your own function for handling writes, where you would use your (presumably existing) backend application API to persist the writes to Postgres. Therefore you can handle any validation/authZ/business logic for writes in your backend layer. The PowerSync client SDK still handles the queueing and retrying of writes so that they can…
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#135Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#136Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#137It looks like the "Switch from X" buttons don't go anywhere.