This would likely need to be done in the browser itself, not in the Worker.
This would likely need to be done in the browser itself, not in the Worker.
IThe Worker delivers the HTML but after that it has no control over the page, only the browser can change things at that point
Vyeah thats what i thought. I cant solve this with a worker, thanks
AGuys, does anyone know if I put assets in Workers they are charged?
IIf you embed them in Workers then no, but there's a max size limit of 25MB on the paid plan and 1MB on the free plan (for all assets + worker combined). If you upload them using the
[sites]
HBTW guys, for the problems I was having
honoittyAnd is there any way I can put images to be loaded from the worker without using buckets or external links? I say this because I wanted, for example, to display an image directly in the worker (this image is currently in the same directory as my worker javascript file) or instead load javascript or css files without having to go to R2, for example. Would? Where would I find specific documentation for this?
B@HardlyWorkin' can you explain what is
ctx.waitUntil
HBetterKV is able to serve a request from cache, while revalidating with KV. To allow you to respond as fast as possible, it uses
waitUntildoes
bKv.putKind of? It puts the value into KV and the local cache, but that does not affect cache in another datacenter
HWhich is why the revalidation system is used
Bif i change the value of a key, how do i assure the revalidation happens everywhere?
HYou can't. It will happen eventually, but if you put a value in one datacenter, it can take ~60 seconds or so at a minimum to be visible globally
Bafter client requests or will it happen automatically?
HWith BetterKV, or without?
Bwith betterKV i think revalidation can happen throughout data centers cause you can just
cache.deletecache.putWith BetterKV and no manual intervention, then it can take one request before it shows the new value(depending on whether or not the original is still in cache). For KV, it can be around a minute since the last access(or more, if you set the cacheTtl to be higher).
Ba minute is fine but how much longer can it take?
Bwell i dont tihnk it matters if betterkv does invalidation by itself
HBasically, with KV, you can receive a value from two places:
- KV Origin
- KV Cache
The KV origin should always have the latest value globally(barring network issues). So, if your KV.get hits the origin, great! You got a fresh value!
HYes, though note this happens after it first serves a request from cache(assuming it qualifies for revalidation).
Bso if i have a have a cacheTtl of like a year, betterkv will still invalidate after a single request?
HWell... Derp. I just realised, that's what it should do...
HBetterKV v2 was built to take advantage of KV v2, which also did background revalidation
HThus, it sets the KV
cacheTtlBut, because KV v2 was set aside, now it will attempt to cache that stale value for a year, without revalidating...
HTheoretically, it is still correct, if you are using KV v2.
Bset aside? i thought the current version is betterkv v2
Bsince tere's a
old.ts in the directoryHYes. The current version of BetterKV is v2. But KV itself also had a v2
HWhich they rolled back due to some issues
Bhow recently?
HI have a message about it being rolled back in November, but I'm pretty sure it happened before then. Don't remember the exact date
Boh sht and they havent given any news about it ever since?
HNot anything that I have heard. AFAIK the KV team member that was working on it no longer works at CF
Blmao
Bvery unfortunate
HSo if you use BetterKV v2, then you probably want to override
kvCacheTtl to 60 insteadHSo that it can revalidate as fast as possible
Bwill that increase kv billable reads significantly?
HNo, because whether or not it is cached, a read from KV itself is always billed.
HI'll push a change to the defaults when I get time
Bcache api is not involved anymore or what? wasnt the point of the cache api to reduce kv reads ?
HI meant that, the logic that determines whether to read from KV is the same no matter the TTL you set for KV
HSo even if I set it to 60 seconds rather than a year, I would still have the same number of billable requests
Bthats for actual kv reads, but with cache api being with a high cache ttl, shouldnt it avoid kv reads to begin with?
HBy default it is set to 55 seconds, at least at the moment, if that is what you mean
HThough the revalidation logic means that it increases in likelihood the closer it gets to the limit
