Kyle Mathews
@kam
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
5 replies
3 recasts
36 reactions
kk
@king
seems expensive
1 reply
0 recast
0 reaction
Kyle Mathews
@kam
which part?
1 reply
0 recast
0 reaction
kk
@king
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.
1 reply
0 recast
1 reaction
Kyle Mathews
@kam
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
1 reply
0 recast
1 reaction
kk
@king
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.
1 reply
0 recast
0 reaction
Kyle Mathews
@kam
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
1 reply
0 recast
1 reaction
