Also, how does KV differ from a CDN (like CloudFront) caching JSON responses? Since both of the solu
Also, how does KV differ from a CDN (like CloudFront) caching JSON responses? Since both of the solutions go to the origin in case of a cache MISS
HYou pay a flat fee for transit to the origin, whether it is the same colo, or across the world. Plus, you benefit from 
’s routing to get to core faster
’s routing to get to core faster
BIf your key has insanely low cache hit rate (typically means you have a lot of cardinality in the key name) then I agree KV will be a bad fit. In practice though, we find access patterns don't demonstrate high cardinality and thus the high cache hit ratio means you're rarely getting the worst read times. Additionally, with https://blog.cloudflare.com/faster-workers-kv-architecture/, we amortize the cost of cold reads within your region and then globally. You'd have to be doing a read of a totally never before seen key every single time.
Additionally, if you're worried about things getting evicted from the cache because the keys are infrequently accessed, I'd recommend setting a very high cacheTTL. It doesn't alter whether you see the update, but it can help with keeping TTFB down for infrequently accessed keys. The only caveat to consider is in a security context (e.g. if you're storing access tokens, the cacheTTL would map to the revocation TTL you can promise)
Additionally, if you're worried about things getting evicted from the cache because the keys are infrequently accessed, I'd recommend setting a very high cacheTTL. It doesn't alter whether you see the update, but it can help with keeping TTFB down for infrequently accessed keys. The only caveat to consider is in a security context (e.g. if you're storing access tokens, the cacheTTL would map to the revocation TTL you can promise)
TIs there a standard practice on using a single vs multiple KV stores?
Say I have two entities to store X and Y. I'm debating between:
1) Having three KV stores: dev, staging, and production. Then using keys prefixes to differentiate "x:<ID>" and "y:<ID>"
2) Having six KV stores: dev-X, dev-Y, etc. Then using simple keys "<ID>".
Approach #1 seems a little messier since you're co-mingling data, but I'm actually having a hard time figuring out why I would care about that.
Approach #2 seems simpler in that I only need to setup one KV store namespace in my app.
Say I have two entities to store X and Y. I'm debating between:
1) Having three KV stores: dev, staging, and production. Then using keys prefixes to differentiate "x:<ID>" and "y:<ID>"
2) Having six KV stores: dev-X, dev-Y, etc. Then using simple keys "<ID>".
Approach #1 seems a little messier since you're co-mingling data, but I'm actually having a hard time figuring out why I would care about that.
Approach #2 seems simpler in that I only need to setup one KV store namespace in my app.
JI’d probably go with #2. It’s not going to make much of a difference as you noted, but #2 brings the benefit of being able to completely nuke an environment’s data very quickly by just dropping and recreating that namespace if ever needed.
UI personally would do #1 helps especially if you want to do somewhat complex queries of related data doing a list by prefix but if you never want to do that it doesn’t really matter then 
BI typically would have dev comingled with staging (maybe with an injected prefix if I'm worried about name conflicts). Whether I do 1 or 2 would depend on the relationship between the keys. If it's the same logical service, I'd probably go with 1. If it's different logical services I'd go with #2. I distinguish a logical service from whether it lives in the same worker by the functionality it's accomplishing (e.g. if you know you have a service hiding within the code of another). In practice though, #1 is often the choice.
TYeah, I'm leaning towards approach 1 for this use case. The data is used by the same service(s) and would get created/destroyed together.
TKinda seems like KV stores are much like logical groupings of data. Keeping data isolated properly, rather than individual datatypes.
TI treat dev and staging differently because dev is a mix of dirty data. I put bad stuff into dev and nuke it all the time. Staging is at least attempting to be as clean as production.
Shttps://github.com/cloudflare/cloudflare-go/blob/master/workers_kv_example_test.go#L107
I think i'm having an issue to get the accont id, can it be to any domain?
I think i'm having an issue to get the accont id, can it be to any domain?
GitHub
Go library for the Cloudflare v4 API. Contribute to cloudflare/cloudflare-go development by creating an account on GitHub.
UDont know what you mean? A domain doesnt have a different account id unless you are using multiple accounts?
Ssorry if it was a silly question
Swhere do I het the account ID
Sas when I go to a domain, each one has a different account id
Sbut i don't see where else would that be
UIf they have different account ids then they are on different accounts so you would go to whichever account your KV is on
Sgotcha, maybe that was the reason
Syeah that was the reason, i checked two differnt domains that have different owners
Sthanks fir the help
S@Unsmart | Tech debt another one
S
Sdoesn't have the WRITE permission
CEdit is the same as write
Sthen when I use this key instead of the global one, it gives auth error
Sbut when i do the response curl it works, any idea?
Snvm, got it, it was a bearer token 
Z- Whats the view on a series of writes to the same KV key, say just 1 seconds apart (eg a fussy user repeatedly tweaking and saving some config) and reading back? Is it guaranteed that the reads will show the same order as the writes in that region? Or a page full of settings / config, each of which autosaves into the same KV key when touched.
- Further, would this be considered bad practice? I understand KV is meant for massive reads and occasional writes.
B- It may work in a lot of cases, but there's no guarantee because KV is eventually consistent.
- The limit for writing to a single key is once per second. The system will error if you try to do it more frequently than that. While it's not a bad practice, if you have a lot of write volume overall (lots of different keys), we might start to rate throttle you (it's unlikely you'll be doing enough volume, but just keep that in mind).
BNot at this time, no. The system auto-purges on writes from upper tiers (https://blog.cloudflare.com/faster-workers-kv-architecture/). We've talked about it, but our current thinking is to work on exposing a tunable
refreshTtl parameter to .get that lets you set a lower consistency value. However, there's a bunch of stuff we have to do under the hood to support that.HAny plans to add a way to reset expiration when getting a value?
BWhat does this mean?
HSome way of adding
expiration/expirationTtl to a get()Changing the expiration requires a write and having read operations secretly write isn't a good idea for multiple reasons.
HNo, I mean that it would be explicit, like
get(“someKey”, {expirationTtl: 1800});. And it seems like overkill to have to rewrite a key every time to reset the expiration timer…HSo a get would never be implicitly be making any changes
BFrom the perspective of the system, it boils down to a HTTP GET. That it internally has custom parameters to say "but actually do a write" doesn't matter so much - you're asking for a read operation to secretly mutate.
The challenge with such a proposal is that the entire point of GETs is to be cached & not hit the underlying storage. If you specify the
If you need this behavior today, you could do something like:
Of course this is race condition prone and would need conditional uploads (not implemented at this time) or mediation through something like a DO.
The challenge with such a proposal is that the entire point of GETs is to be cached & not hit the underlying storage. If you specify the
expirationTtl, that defeats the purpose since you need to hit the storage. And what happens if we fail to update the TTL is that an error? If yes, then we'd have to wait for the response from the storage & it's not cacheable. It would have to be no which means there's no way to signal to the user that we failed to update the TTL.If you need this behavior today, you could do something like:
Of course this is race condition prone and would need conditional uploads (not implemented at this time) or mediation through something like a DO.
ZGot it. Is there any service in the Cloudflare offerings that can be used to create a debouncer in front of KV writes.
BDurable Objects. A common mechanism is to use DOs as the "ground truth" for storage operations & KV is the read path in front.
ZYup, I'm already using DOs for suitable use cases - multi-location sync / multi-user sync etc. But there's a lot of complexity etc involved with DO, whereas KV is very clean. So I'm wondering whether there is a way to debounce writes to KV. I though queues might be a way, but I dont suppose that would have such a feature either.
BBy debounce you mean to make sure the value is read/modify/write updated atomically in a safe way? Or something else
ZJust a simple way of reducing multiple writes to the same key to the last write once there is a pause. Eg
edit #1, save #1 - this produces a KV write
edit #2, save #2 - this produces a KV write
.
.
.
edit #5, save #5 - this produces a KV write, all within few seconds.
<pause>
A debouncer would just take the 5th KV write, since earlier superseded by #5. No read being done in this set of ops.
edit #1, save #1 - this produces a KV write
edit #2, save #2 - this produces a KV write
.
.
.
edit #5, save #5 - this produces a KV write, all within few seconds.
<pause>
A debouncer would just take the 5th KV write, since earlier superseded by #5. No read being done in this set of ops.
BAh. Queues is probably a nicer mechanism than DOs, although I don't believe it has any ordering guarantees which make things hard.
UQueues also doesnt really have any state so it wouldnt know when the last write to a specific key happened to debounce it properly. DOs would realistically be the only option to debounce writes like that.
Would also limit you to writing 128KB values unless you used multiple DO keys to save the value and then do a list or something
Would also limit you to writing 128KB values unless you used multiple DO keys to save the value and then do a list or something
UIf you are ok with the slight chance of losing some data I feel like the easiest option might be to just block the request until at least 1 second from the last write and if you have many requests come in a single second do a fake success return for the previous write and then only the latest value will be waiting for 1 second to then write to KV
ZCertainly DO can be used - I'm already using it as a debouncer in some cases by setting and canceling+setting the alarm on each update, and the last set alarm will finally trigger. Thats how I handle a stream of actions generated within the DO, eg notifications. But was looking for a simpler more elegant way to do this with KV.
BUnfortunately not. You need to put a FIFO queue in front. Since queues doesn't yet have a FIFO mode, you'd need to roll it manually via a DO.
B@HardAtWork you maintain the BetterKV project, right?
HYeah, I do
