# workers-discussions
- k
kian
03/09/2023, 2:33 AMyep - d
dave
03/09/2023, 2:34 AMCopy codejavascript const resp1 = await fetch(url) const my_promise = fetch(url).then(async (response) => { return env.R2.put(key, response.body) }) ctx.waitUntil(my_promise) return resp1 - d
dave
03/09/2023, 2:34 AMthat's it - d
dave
03/09/2023, 2:35 AMI'm actually gonna be using the Cache API instead of R2 - d
dave
03/09/2023, 2:35 AMso my limit is 500MB - t
Tom Sherman
03/09/2023, 7:38 AMWhy would you want to call your API twice? That's just wasteful, you're using the same amount of memory but doing two requests... - t
Tom Sherman
03/09/2023, 7:40 AMThis example should only use memory to hold a few chunks of the stream at a timeCopy codejs const res = fetch(url) waitUntil(kv.put(key, res.clone().body)) return res - t
Tom Sherman
03/09/2023, 7:42 AM@dave It doesn't matter how large the response is, you'll only ever use a few megabytes - d
dave
03/09/2023, 2:08 PMI was worried that I could end up accidentally buffering like ~300MB if the original (or cloned) response is read back really slowly, while the other is fast. - t
Tom Sherman
03/09/2023, 2:09 PMwhen you're piping a stream directly to a destination, there is very little buffering. that code in deno will buffer a max of 16MB for example. i don't know what workers would do, but it's gonna perform similar i'm pretty sure - t
Tom Sherman
03/09/2023, 2:11 PMHmmm actually rereading what you're saying, I'm now doubting myself 😅 - d
dave
03/09/2023, 2:11 PMthe API is basically "free" to call, so that's why I'm not against calling it twice. - t
Tom Sherman
03/09/2023, 2:12 PMAtomicity not a problem here? - d
dave
03/09/2023, 2:12 PMooouf. uh. - d
dave
03/09/2023, 2:13 PMI think no. - t
Tom Sherman
03/09/2023, 2:13 PMruh roh - d
dave
03/09/2023, 2:16 PMactually should be fine - t
Tom Sherman
03/09/2023, 2:16 PMyou might be able to send it to kv, and then read it straight back out again. i think the consistency allows for thatCopy codejs const res = fetch(url) await kv.put(key, res) return new Response(kv.get(key), res); - t
Tom Sherman
03/09/2023, 2:16 PMbut then you gotta wait for the KV upload - d
dave
03/09/2023, 2:17 PMoh I only want to put it in the Cache API - t
Tom Sherman
03/09/2023, 2:17 PMoooh - t
Tom Sherman
03/09/2023, 2:18 PMnot sure how that changes things tbh 😆 - d
dave
03/09/2023, 2:20 PMit's best effort anyway - a
Advany
03/09/2023, 2:56 PMI store JSON config per host inside KV. It has a 60-sec delay before being available globally (that's not a problem for regular usage). But I also want to add preview mode where the JSON value stored inside KV is available quickly. I can store that value when the KV is set also to DO, R2, or D1. I only require the "live" value when someone wants to preview. It doesn't have to be fast and will only be used directly after the value is set to preview if things are working as expected. Which storage is the most recommended option for such a use case? I was thinking D1... - a
Avinash
03/09/2023, 4:12 PMI want to write to KV from browser. Should I have to use Workers mandatorily? Or I can directly invoke CloudFlare API from the browser? - s
Skye
03/09/2023, 4:13 PMYou should not do it directly from the browser - that would mean your API tokens are exposed and anybody could write what they want to your namespace - s
Skye
03/09/2023, 4:14 PMIt also means they could put many gigabytes there and charge you for it - s
Skye
03/09/2023, 4:14 PMYou should definitely control access through a worker - c
Cyb3r-Jok3
03/09/2023, 4:18 PMYou also can’t use the Cloudflare API directly from the browser as it doesn’t implement CORS for Skye’s reason - d
dave
03/09/2023, 8:31 PMI'm having a really weird issue where tail logs seem to be really delayed, or worse, missing