currently DOs run in 5 pops in western north america and 5 pops in western europe. We plan to add at least 15 more before leaving beta, including 5 in Asia

haha, no wonder my DO latency isn't great, lol. especially when i'm logging through a tokyo-based ngrok endpoint and jumping across the pacific twice.

but clearly updating KV from the DO and not the worker is an anti-pattern.

(if you want it reflected to the end client ASAP, that is)

yeah KV writes take a while to read datacenters other than the one that performed them. That's something I want to fix by rebuilding KV on DO, actually. 🙂

LOVE IT

rebuilding KV on DO will also probably make the APIs more consistent too, i guess?

hmm, I wasn't imagining any API changes

more of a transparent performance improvement

ah, i see. tho i'd love structured clone in KVs, and you might not have to change the API there?

ie, putting POJOs instead of JSON strings.

also you could add

reverse

pretty transparently.

yeah that would be cool. That's something we could do separately. Biggest issue is backwards-compatibility with existing data.

(structured clone serialization I mean)

right now, the caller specifies what type get() should return, and it coerces between text and bytes... in a structured clone world, if you put() an ArrayBuffer, get() should return ArrayBuffer with no need to specify it

maybe we could make it be a per-namespace flag though

oh yeah the other problem is what to do in the HTTP API (api.cloudflare.com)... it's not obvious how to represent V8-serialized objects there. It's not isomorphic with JSON.

but we could just... not let you use the HTTP API for such namespaces?

hmmm, good point.

i mean i guess you could add your own serialization (via data urls, etc) but it wouldn't be pretty.

(basically it'd be like what JSON does with dates.)

or maybe users could somehow specify their own replacer/reviver functions, but it gets a bit hairy.

well, the right place for people to implement custom conversions to JSON would be... in their worker. So not using the CF API.

right, i was thinking they could specify a script name in the API or something.

but at that point they're building their own API anyway, lol.

ie, api.cloudflare.com doesn't make a ton of sense anymore.

anyway if you rebuild KV on DO, consider making the legacy API a shim... would be much easier to reason about the platform if the APIs were the same.

like, for example, the HTTP request schema is different between lambda and lambda@edge and it's really annoying.

ie, the edge version and and regional version shouldn't need to have different APIs.

(if you see KV storage and DO storage as the “everywhere” and “anywhere” flavors of the same product, that is)