D1 read replication was not available when I started working on FlagShip. However, since I only use D1 for storing data like project configuration, replication was not really necessary.
The flags consumed by the clients are pushed to and read from KV alone. KV already has geo replication out of the box, although there still is propagation delay for updates to KV.
It would be nice to have everything served from D1, I might consider it when replication is stable enough.
Thank you. It's mostly because of costs (free tier).
I mostly use KV for storing flags specific to each project (which gets replicated automatically). Everything else goes to D1 (replication isn't needed here).
Cloudflare queues was something I might consider for async workflows.
Neat! Love the ability to deploy some like as powerful as Launch Darkly effortlessly with Workers.
D1’s read replicas [1] is still pretty new, how has this worked out for a read-heavy workload like FlagShip?
[1] https://blog.cloudflare.com/building-d1-a-global-database/#s...
Thank you!
D1 read replication was not available when I started working on FlagShip. However, since I only use D1 for storing data like project configuration, replication was not really necessary.
The flags consumed by the clients are pushed to and read from KV alone. KV already has geo replication out of the box, although there still is propagation delay for updates to KV.
It would be nice to have everything served from D1, I might consider it when replication is stable enough.
This is a neat use of Cloudflare workers. Is there a reason you chose D1 and KV over using Durable Objects?
Thank you. It's mostly because of costs (free tier).
I mostly use KV for storing flags specific to each project (which gets replicated automatically). Everything else goes to D1 (replication isn't needed here).
Cloudflare queues was something I might consider for async workflows.