With the eventual consistency caveat of KV, does that mean it's impossible to do "append" operations
With the eventual consistency caveat of KV, does that mean it's impossible to do "append" operations with them?
EYeah, pretty much. If one worker tried to append then it may be reading stale data and then another worker in a different location also tried to append and suddenly your count is completely wrong.
For counting or appending things reliably and consistently I believe #durable-objects are best suited
For counting or appending things reliably and consistently I believe #durable-objects are best suited
BBut durable objects are being charged for its lifetime, no?
BI'm thinking doing a like system similar to most social media sites (users can like a content, and users can see how many likes a content has) and I'm feeling maybe serverless is not the way to go.
Eim gonna go ahead and repost this here, it was incorrectly flagged
Ethough half of it is still missing i think
BTrue, serverless was the wrong word there.
BI'm not very good at backend or infrastructural stuffs, and my project does have global presence
BThere are DBaaS with global replications, but I'm also trying to see if I could work CF into what I need.
AYou would only be charged whilst they are doing things. So, in your case, the few milliseconds needed to add or retrieve a comment. It's only when you are using we sockets that they run all of the time
BI wasn't aware, that changes things.
BWhat are you guys thoughts regarding this (implementing a content like system with CF KV/durable objects, instead of a database)?
BI figure there should be far more reads (viewing a content) than writes (liking/unliking a content) and can benefit from global fast delivery, so CF KV seems like a natural good fit.
EOh yeah.. that dashboard absolutely needs some love.. it needs a search box even more than it needs checkboxes (which it also very much needs tbh)
ZI believe it's something custom
EIt is a mix of existing and custom build logic.
Wthey're replicated between the storage servers yes
WBut the latency around AUS/Asia can be quite high for a cold read
WNA/EU high yes
Wsadly
EI find they are usually in the 200-300ms range, which is probably about as bad as you can get.. South America might see slightly higher ones depending on where and network quality?
EI am in Australia btw
WBlog post on all this eventually
EWoohoo!
Jdon't you mean 
JCan someone help with this
WThe getAssetFromKV should map the asset to the hashed one.
@cherryjimbo is best to answer but I can try until he's around
What I'd recommend first is just passing in the request you're given rather than making a new one. So,
I also see in the docs for kv-asset-handler it'd also like waitUntil (though not sure why exactly) so maybe try to pass that in too.
Then unrelated, your error is trying to get the request from the request. That should just be
@cherryjimbo is best to answer but I can try until he's around
What I'd recommend first is just passing in the request you're given rather than making a new one. So,
getAssetFromKV({ request: req })I also see in the docs for kv-asset-handler it'd also like waitUntil (though not sure why exactly) so maybe try to pass that in too.
Then unrelated, your error is trying to get the request from the request. That should just be
event.url (the naming for that request is definitely confusing so I'd maybe suggest renaming it too)
HEither via API calls, or through a Worker Proxy.
ENo.. hopefully it is an entirely different experience.. 
And if you can do that, you should totally file a HackerOne bug bounty, and it would make you quite a nice bit of cash I am sure
And if you can do that, you should totally file a HackerOne bug bounty, and it would make you quite a nice bit of cash I am sure
ENo, I mean between different accounts. Two workers on the same account is absolutely no problem and is supposed to work
ENo worries, we are always here to help!
EYeah, you can't do that with the native KV namespace API. But you can use the API key through the Cloudflare API at https://api.cloudflare.com
ANevermind, this is not an issue with KV, instead this was an issue with how I'm sending the request to my worker.
WKV works by having central storage then on read caching the value at the PoP. So, a high initial read value is indeed expected and then it'll sit at ~10-25ms
Here's a graph of initial read times in a bunch of areas
Here's a graph of initial read times in a bunch of areas
