[simonw]

Does this change your mind at all? https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...

It looks to me like they've documented the KV Connect protocol they invented to support this feature, in enough detail that anyone else could build an alternative backend for it.

This has helped me feel completely OK with how they're handling this. They get an advantage in that they've already built an extremely robust proprietary backend, but I find that acceptable given the documented protocol.

[crabmusket]

I think this is great, except I feel odd that it's just hanging around on the Deno global instead of being e.g. imported like any other database client.

    import KV from "https://deno.land/kv" // for example

If their protocol is indeed open and usable with your own backend, then that library should be able to work for anyone. And if they need some fancy native performance then maybe they could intercept that import when running code on Deno Deploy?

Treating their hosted service as "part of the runtime" which is what the Deno global tends to be for is the only remaining ick factor for me.

[wink]

Yeah, this is the only thing I don't like. Having it readily available as a module import would not change anything (except one line of code) and it feels more decoupled. But in practice I don't see a huge difference, it's not like it's polluting the global namespace with dozens of functions.