docs(cloudflare): minor updates to the caching doc#180
Conversation
|
|
||
| A queue must be setup for projects using revalidation (either Time based or On-demand). | ||
| A queue must be setup for projects using Time-Based revalidation. | ||
| It is not needed when revalidation is not used nor only On-Demand revalidation is used. |
There was a problem hiding this comment.
I think i know why there was a mention of On-demand, res.revalidate use the same binding that the one used by the queue. We only talk about it in the queue part of the docs
There was a problem hiding this comment.
Do you suggest to update the the doc as:
-A queue must be setup for projects using Time-Based revalidation.
+A queue must be setup for projects using Time-Based revalidation or `res.revalidate` (Page Router)
It is not needed when revalidation is not used nor only On-Demand revalidation is used.There was a problem hiding this comment.
I guess we could put it here, but it's not actually the queue that is needed it's only the binding itself.
Maybe we don't need the fix anymore actually, since now fetch are public if i'm not mistaken (We had to use the binding, but now it can just be a fetch, which i think is the default)
There was a problem hiding this comment.
We had to use the binding, but now it can just be a fetch, which i think is the default
The binding will always be faster than a public fetch as it will skip part of the Cloudflare infra.
So we decided to keep using the binding for internal code to benefit for the improved perf.
I'll double check what we do currently.
8ef3f37 to
8dec01c
Compare
CACHE_PURGE_API_TOKENandCACHE_PURGE_ZONE_ID