Cloudflare

To answer the "best way" part of your question: it is definitely bindings. Your request can talk to R2 directly then, instead of having to (possibly) go over the public Internet

Thanks, that's super helpful, I'll switch it then. Does it make sense to use CF worker custom cache or can I just get the object from R2 on every request just like in this official example https://developers.cloudflare.com/r2/api/workers/workers-api-usage/#4-access-your-r2-bucket-from-your-worker.

<@136415155016826880> we've switched from fetching R2 data to native bindings and... things got worse. Our latency went up from 1.5ms to 2.5ms and so did our execution duration. That is even with caching content from R2 and avoiding things like re-compressing content. We're puzzled... our cache hit rate is also pretty low (way lower than cache hit rate from `fetch`). Is this normal?

Are you using the Cache API in your Worker? Your zone’s cache rules won’t apply inside a Worker, which may be why your hit rate tanked

Yep, we use Cache API, which works like this
```
const cacheKey = new Request(url, request)
const cache = caches.default

// Check whether the value is already available in the cache
// if not, fetch it from R2
response = await cache.match(cacheKey)

if (!response) {
  ...
  ctx.waitUntil(cache.put(cacheKey, response.clone()))
}
```
We don't have any special cache rules. Our cache rate for subrequests (to R2) was very high but plummeted after switching to Cache API. Is it possible that subrequest caching is somewhat "smarter" and hence results in a higher cache rate?

It looks like R2 native bindings don't have any extra benefits over simply making additional requests to R2 (except for getting rid of occasional 502s from R2).

Hm I’m going to have to look into this hunch about smarter subrequest caching