Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
71–80 of 173 posts
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#72Any specific reason it wouldn't work with Angular as well (noticed it was not listed in the Frontend frameworks section)?
Not at all, it's perfectly possible to use it with Angular. While we haven't built any specific helpers for Angular, like we have for React, our TypeScript client is perfectly useable from any JS/TS framework or project.
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#73Does this play nice with RLS? I’m running everything on Postgrest at the moment.
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#74Wow, this is awesome! I've been "waiting" for a project like this for years - having to roll out my own syncing solution for my local-first app until now. I have yet to dive deeper in the docs and examples, but does anyone know how easy it would be with Electric to provide some kind of client-side transformations (encryption/decryption) of specific fields or entire rows in your SQLite db before syncing? A major reaso…
Valter from Electric here, Handling encryption/decryption of user data is one of our priorities. We're thinking along the lines of adding hooks for transforming data as you're seeing it. We're getting there on permissions implementations. If you want to do row-based filtering based on user_id today, you can add a special column 'electric_user_id' to your table: https://electric-sql.com/docs/reference/roadmap#shapes W…
E2E encryption would also be nice to have, it could be worth having a look at https://www.etesync.com/ for inspiration
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#75I am curious about encryption. Assuming that ElectricSQL is handling essentially all of the syncing, is it possible to build applications that use end-to-end encryption for some of their state? I am wondering specifically because CRDTs seem to simplify E2EE a lot since well, any client that can write can resolve conflicts any time. I haven't looked very deeply yet as I've been very busy, but to me that's the main thing I've been really curious about. I know you can at least do this with Y.js which helpfully provides a way to use symmetric encryption for WebRTC synchronization, but this obviously is a whole lot more than that.
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#762. Is there a way to disable auto resolving of conflicts? i.e to let the user know of the conflict?
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#77Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#78I am extremely, extremely excited about this. I was wondering: what is the difference between VLCN and ElectricSQL? Thank you!
Hey, James here, one of the co-founders of Electric. Both projects are doing active-active CRDT-based sync. Our focus is on sync via Postgres and on compatibility with existing Postgres-backed applications. So you can drop Electric onto an existing Postgres-backed system and it works with your existing data model. There's also quite a lot of difference in the development model, how we handle migrations, shape-based p…
Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps
#79I have a side project where this would fit perfectly. I’ve for a database in Postgres and my plan have been to sync the data into a local SQLite for a react-native app which needs to work offline and with flaky connections, to then later sync it back into PG. I have never gotten around to actually build the sync and it looks like this could solve that problem. Does this play nice with RLS? I’m running everything on P…
Re: RLS, not quite, you'll need to port your rules to our DDLX syntax https://electric-sql.com/docs/api/ddlx -- which is not fully implemented yet (we're working on right now, will be available shortly).