@anthony ooo.. looks like mupdf can handle streams.. <https://github.com/ArtifexSoftware/mupdf.js/bl
@anthony ooo.. looks like mupdf can handle streams.. https://github.com/ArtifexSoftware/mupdf.js/blob/master/examples/tools/split-pages.js
DWhat's the fastest/highest perf way to validate an incoming request for valid JSON?
DHmm, that’s gonna require buffering the whole thing in memory first though. 
DI don’t think CF would even notice at that tiny volume.
DYou can do a fetch with zone caching enabled too iirc.
AInteresting, going to look into this!
JAWhat range of pdf sizes were you having trouble with btw?
JOnly 2MB, so didn't have memory issues, but nearly 200 pages, so took 5 seconds or so.. but fast enough that I could just process it in response to a request
AHow to download and display images from Workers R2 binding on a page using Javascript?
Shey @Unsmart | Tech debt @MetalGear is this still work in progress?
HHello! I was looking at this example https://github.com/cloudflare/js-rpc-and-entrypoints-demo/tree/main/public-admin-api-interfaces about using a dedicated worker for DB interactions using RPC for inter-workers calls.
From my understanding of the docs, RPC calls are usually executed in the same machine.
However, workers with D1 attached are usually executed closer to D1.
In this case what would happen? Will this RPC call happen in the same machine with the trip to D1 location or the RPC call will happen via network?
Example:
worker-db with a D1 attached in EU
worker-front with service bind to worker-db
Then worker-front receives a request from US, which usually happens closer to the user.
What will happen then?
1 - worker-front and worker-db executed closer to user (US) and network trip to D1 db?
2 - worker-front execution in US and RPC call via network with worker-db running closer to DB (EU)?
3 - Both workers executed closer to DB (EU)?
4 - Something else?
From my understanding of the docs, RPC calls are usually executed in the same machine.
However, workers with D1 attached are usually executed closer to D1.
In this case what would happen? Will this RPC call happen in the same machine with the trip to D1 location or the RPC call will happen via network?
Example:
worker-db with a D1 attached in EU
worker-front with service bind to worker-db
Then worker-front receives a request from US, which usually happens closer to the user.
What will happen then?
1 - worker-front and worker-db executed closer to user (US) and network trip to D1 db?
2 - worker-front execution in US and RPC call via network with worker-db running closer to DB (EU)?
3 - Both workers executed closer to DB (EU)?
4 - Something else?
GitHub
Contribute to cloudflare/js-rpc-and-entrypoints-demo development by creating an account on GitHub.
NHey guys!
Might be a dumb question but, is the Cloudflare workers cache API suitable for credential and authorization policy caching?
Would it be secure to store this kinds of sensitive information in a custom cache instance (cache.open)?
Are cache instances guaranteed to be private inside a CF account?
Might be a dumb question but, is the Cloudflare workers cache API suitable for credential and authorization policy caching?
Would it be secure to store this kinds of sensitive information in a custom cache instance (cache.open)?
Are cache instances guaranteed to be private inside a CF account?
HThey are guaranteed to only be accessible within your account. You can even use a fake URL like
https://mystore/somepersonNthat was exactly my main worry, i, currently using something to the lines of https://<tenantid>.policyengine/<role>
i was worried if collisions with other accounts were a risk
i was worried if collisions with other accounts were a risk
Nthank you for the clarification
LCan I call multiple user workers from a dynamic dispatch worker in a single request?
NAbout the cache purge situation, is there really no way to purge a single URL outside the enterprise plan?,,
Thats inviabilizes the idea.. if so i might need to go to KV or Redis instead
I was thinking of using it as a Cedar policy cache, i managed to run the recently open-sourced cedar policy engine (the AWS permissions engine) inside a rust worker, and im trying to build a low cost api gateway alternative with CEDAR policy resource management suport. adding the requirement of one or more kv requests per api call seems a shame while having an amazing cache api, but an authorization service without near instant policies updating seems.. wrong
Thats inviabilizes the idea.. if so i might need to go to KV or Redis instead
I was thinking of using it as a Cedar policy cache, i managed to run the recently open-sourced cedar policy engine (the AWS permissions engine) inside a rust worker, and im trying to build a low cost api gateway alternative with CEDAR policy resource management suport. adding the requirement of one or more kv requests per api call seems a shame while having an amazing cache api, but an authorization service without near instant policies updating seems.. wrong
HFor Zones on Free/Pro/Business plan, you may purge up to 30 URLs in one API call
HThough this only applies to
caches.defaultOh.. thats.. ok i guess?
Would it be ok to save the cache in the default cache while using a fictional url like we talked about above?
Would it be ok to save the cache in the default cache while using a fictional url like we talked about above?
LAnd if so, how would that be billed?
HIt should be fine. You could even use a real URL that isn't on your account, like
google.comNIf that URL never comes to actually exist, and be publically hosted in my CF account, theres no risk of the contents being exposed, is that correct?
NIf thats not too much to ask, would you be able to provide me with a link to the docs for that API call or SDK? On the cache documentation i only found the prefix based cache purge (marked as Enterprise)
HInteract with Cloudflare's products and services via the Cloudflare API
NThanks!
Ill try it out, if i have good results (and performance) ill probably open source my cedar-policy-on-cf repo
Ill try it out, if i have good results (and performance) ill probably open source my cedar-policy-on-cf repo
NRight now im getting 3ms for policy lookup, parsing and allowed/denied outcome on a 20 entities, 10 principals setup, seems amazingly quick! With added JWT parsing (and maybe caching with TTL equal to token exp) im thinking ican keep it under 25ms total, which blows AWS API Gateway out of the water!
HI’d say no. Some places even just use 6 digits. Though, you could probably go much longer if you made it a link
Sis there a way to decrease number of requests for workers , as each visit to my website is hitting the worker hundreds of time , for each path , and for each request it count 1 request
?
?
Seach visit cost me more than 1000 request worker , I just need the worker to work 1 time for each ip address
Sthe md5 option in r2 bucket#put accepts arraybuffer and string. I input a hexadecimal string however,
the bucket response#checksums#md5 returns an arraybuffer regardless. How do i get it as a string, does cloudflare change it in any way while storing it?
the bucket response#checksums#md5 returns an arraybuffer regardless. How do i get it as a string, does cloudflare change it in any way while storing it?
HYou have already asked this question
Sand no one answered me
Sthe answer was not related to my question which was to decrease number of requests
SI just want to trigger 1 worker request for each ip address
HBut basically, if someone makes multiple requests to your Worker, then you will be billed
SI just want to trigger the worker 1 time for each ip address , is there a way to control that
HThat’s not a thing, no
HUnless you make requests go over a WebSocket or something
Shmmmm thank you
Hcan a worker that acts as a backend for a react page hosted on cloudflare pages have the same origin?
Ljust in case if anyone wants to know, it's in documentation
" Each incoming HTTP request or WebSocket message resets the remaining available CPU time to 30 seconds. This allows the Durable Object to consume up to 30 seconds of compute after each incoming network request, with each new network request resetting the timer. If you consume more than 30 seconds of compute between incoming network requests, there is a heightened chance that the individual Durable Object is evicted and reset."
" Each incoming HTTP request or WebSocket message resets the remaining available CPU time to 30 seconds. This allows the Durable Object to consume up to 30 seconds of compute after each incoming network request, with each new network request resetting the timer. If you consume more than 30 seconds of compute between incoming network requests, there is a heightened chance that the individual Durable Object is evicted and reset."