Syncing > Querying.

Anywhere you query for data you should consider syncing data instead.

CDN-backed syncing means your data loads faster you get real-time updates for free.

It's like having mini PG read replicas scattered across your system.

What is fundamentally interesting about the shift from query -> sync?

Both answer the question: "how do I copy data from the database?"

Sync gives you two huge advantages:

1. built-in caching so cheap distribution of data via CDNs
2. real-time updates so no stale data

Tech entrepreneur. Founder @electricsql. Founder @gatsbyjs (acquired by Netlify). @kylemathews on Twitter

actually no, i'll agree with you on this. the best take away is the cached data part although we have these components already in existing systems, a local db copy with sync capability just formalizes it.

Right yeah. "Sync engines" are all over the place. They're just all ad hoc. So yeah, formalizing the idea and making it really really fast/scalable/flexible is the innovation

Electric (which I work on) is very lightweight to pull into a project — check out the quickstart — https://next.electric-sql.com/guides/quickstart

You can switch things over query by query or API call by API call — i.e. if there's some data that's pretty heavy to load or you'd like it to update in real-time or if there's a lot of network chatter to get updates or pull over slices — switching that to syncing would be a good test

i've heard about this new paradigm (for web), how is it progressing? seems like something i might take on for new projects but probably won't dare changing it on existing ones without fully committing, it's too built up. besides, a simple patch to reduce the amount of request could easily be used in this case: ask the api if X has an update -> yes, take query, no use the cache.