[dantiberian]

I listened to https://www.localfirst.fm/18 recently from Electric-SQL. One of the things James mentioned was that Electric lets you use commodity CDNs for distributing sync data, which takes the load off your main Postgres and servers.

This seems like a good pattern, but of lower value for a SaaS app with many customers storing private data in your service. This is because the cache hit-rate for any particular company's data would be low. Is this an accurate assessment, or did I misunderstand something?

[thruflo]

Hey, one of the things here is to define shapes that are shared. If you imagine syncing a shape that is that user’s data then it may be unique. But if you sync, say, one shape per project that that user has access to and a small shape of unique user data then you get shared cache between users who have access to each project.

It’s worth noting that Electric is still efficient on read even if you miss the CDN cache. The shape log is a sequential read off disk.

[Ineentho]

I'm curious on how you'd configure this. Is it common (and safe) to let a cdn cache private data for authenticated users?

Say Jira used electric, would you be able to put all tickets for a project behind a cdn cache key? You'd need a cdn that is able to run auth logic such as verifying a jwt to ensure you don't leak data to unauthorized users, right?

[thruflo]

Yup, you can put an auth proxy in front of the CDN, for example using an edge worker.

See the auth guide: https://electric-sql.com/docs/guides/auth

Some CDNs also validate JWTs, so the CDN can be the proxy part of the Gatekeeper pattern (in the guide).

[kylemathews]

Another option too for scaling reads is just putting an nginx in your cluster.

Electric itself is quite scalable at reads too so for a SaaS use-case, you might not need any http proxy help.