Hooks

[thruflo]

We’ve had a few requests for hooks:

1. client side on and off the replication protocol to support encryption
2. electric side to support addition authorisation/validation, potentially with capability to change the row value
3. electric side as an alternative to event sourcing / basically just hooking into the ongoing stream

[KyleAMathews]

A good POV I think for this is that people will want to do all the things they currently do with APIs e.g. restrict the database schema (don't expose some internal-only fields to clients), change the schema (the db team wants to refactor some columns but not break consumers, clients want data represented in a particular way that'd be odd to do in the db so you add a computed field), modify data on the fly, add extra validation/side effects on writes, etc. etc. This HN Discussion has some fun stories from angry engineers trying to work on systems where they can't modify the database much due to strong coupling between the db schema and consumers. I think any long-lived schema would want the decoupling of schemas an API normally provides — particularly ones where different teams (or companies!) control the backend and frontend.

[KyleAMathews]

So a future doc page could have two columns where on the left it lists API use cases and on the right, how to do the equivalent in hooks, DDLX, etc.

[thruflo]

Yup, I’ve had some pages for “Switch to Electric for REST”, “Switch to Electric from GraphQL” etc on my radar to write. And we get questions about how to do common things as you’re listing, like handle schema versioning, adapt data, etc.

[balegas]

We should add to the list above the ability to hook into migration messages to be able to stop replication for breaking changes that the application does not support.

[MentalGear]

Best practices guides for these essentials (like custom data validation) would certainly be much appreciated since I couldn't find anything on that yet! Is there some page writing already in progress?

Meanwhile, I and many newcomers would find it greatly helpful if you could outline where custom data validation, for ex using zod, can/should be done on the backend/frontend stack in electric ?

( even if electric would eventually support check constrains, there are many use-cases were the usage of application level validation logic might be preferred or required. )

[KyleAMathews]

👋 we've been working the last month on a rebuild of the Electric server over at a temporary repo https://github.com/electric-sql/electric-next/

You can read more about why we made the decision at https://next.electric-sql.com/about

We're really excited about all the new possibilities the new server brings and we hope you'll check it out soon and give us your feedback.

We're now moving the temporary repo back here. As part of that migration we're closing all the old issues, PRs, and discussions. We really appreciate you taking the time to start this discussion! If it's still relevant in the new system, please reopen.