Hacker News new | ask | show | jobs
by thruflo 924 days ago
This page lists current limitations https://electric-sql.com/docs/reference/roadmap

The key features for us on this are:

1. permissions https://electric-sql.com/docs/usage/data-modelling/permissio... which are defined using DDLX rules, authorise data access and can be used to filter data 2. shapes https://electric-sql.com/docs/usage/data-access/shapes which are the main, more expressive way to control what data syncs on and off the local device, including where clauses, joins, include trees, etc.

These are both in development and due soon. From your comment, I think you’ve seen the shapes branch with where clauses and include trees already working, for example.

In the meantime, the shapes API over syncs the full table. This is temporary and obviously suboptimal but it means you can develop today using the shape APIs and still filter data you display using local queries. Then when the proper functionality lands, the sync will become more fine grained and optimal without your app code needing to change.

Hope that makes sense. We’re very much not a full table sync system. Our role is to provide the best possible model for controlling dynamic partial replication (and to maintain integrity across replication boundaries).

1 comments

I cannot imagine advocating for using shapes as they currently exist for an access control use case. Shapes may limit what the user can see in the app, but I've now put all of my other users data on this user's device! No way can I pass a security audit with that.