also is it best practises to do 1 R2 bucker per customer? I Assume yes
also is it best practises to do 1 R2 bucker per customer? I Assume yes
SOnly if you have less than 1000 customers.
Take a look at https://developers.cloudflare.com/r2/reference/limits/
Take a look at https://developers.cloudflare.com/r2/reference/limits/
RInteresting , I'm sure they mentioned here they could raise limits
RI'm just trying to follow best flow
HThey should be able to
RYeah I don't mind doing one drive and partitioning g with "folder" prefixes per customer either
RYeah looking for confirm on which makes more sense .
RMy next question is, I see serving static from workers is discontinued? So if my users wanted to deploy frontend static htmk or something what would i do?
HDid Sites ever work with Workers for Platforms? The big thing with Sites was just that it had a package/upload tool(Wrangler) that was supported by the team. Everything it can do, you can build yourself
Ryeah it esbuild or something bundles ur frontend into like static assets? thne id do a dist or static folder and like app.servestatic on hono or something, but i saw in thier docs they said it's been dscontinued
R
WSites was deprecated many years ago
Ryah not sites I was talking about serve static files aspect
WThat's Sites :p
WPages is the recommended way for now
With convergence static assets will come to Workers officially (Sites was always quite a hack) but that's still a way off
With convergence static assets will come to Workers officially (Sites was always quite a hack) but that's still a way off
Rwelp. lol . alright so for WFp if someone wants to deploy static frontend jsut use pages API or something liek that? it won't be able to be served from the same worker ?
HIs there a Pages For Platforms that you can call via a Dispatcher?
HOr something similar
Wno, you can spin up a site though and invoke it (we have customers doing similar just not through wfp)
AI want to pass some custom args to the user worker without modifying the original request. Is this not possible right now? could be a good use case of the second parameter in dispatcher.get(..).
Wjsrpc 
WYou could implement your own fetch handler and pass in whatever you want
WCloudflare Docs
The built-in, JavaScript-native RPC system built into Workers and Durable Objects.
AGotcha, I guess I can do that. Would the
cf object still be stripped when passing the Request through?
Ehi guys, im new to all this so this may be a stupid question.
I want to make a worker that gets visitors data from headers (useragent...) and want to save this somewhere. i saw that there is hyperdrive and as far as i understand it, i can connect my db. are there any limits for reading/writing and also for this kind of worker should i get worker for platforms? are there any benefits?
thanks
I want to make a worker that gets visitors data from headers (useragent...) and want to save this somewhere. i saw that there is hyperdrive and as far as i understand it, i can connect my db. are there any limits for reading/writing and also for this kind of worker should i get worker for platforms? are there any benefits?
thanks
AHey Folks,
In docs here https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/get-started/dynamic-dispatch/
I see that
What if I'm using this with RPC, when the worker is not found I get
In docs here https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/get-started/dynamic-dispatch/
I see that
await userWorker.fetch(request) will throw an error with message that starts with Worker not found if the worker is not found.What if I'm using this with RPC, when the worker is not found I get
internal error. and not Worker not found how can I configure this, or how would I know that if the worker threw exception or not foundCloudflare Docs
After you have created a dispatch namespace, you can fetch any user Workers in the namespace using a dynamic dispatch Worker. The dynamic dispatch …
OI'm the newest one here but I guess you can use cloudflare analytics for that kind of data as it's easy to do time series queries with that besides normal queries. Hyperdrive needs Postgres which you gotta deploy urself or use hosted services and it's maily for read heavy workloads.
AHey folks,
Doing a
But doing a
Any idea why secrets aren't being set?
Doing a
PUT request to /secrets returns this:But doing a
GET just after that to the same endpoint returns this:Any idea why secrets aren't being set?
AI found the issue, but have no idea how to fix it.
So assuming
In other words, the dispatch namespace in this API has no effect it just looks in all the user workers on the account and picks the first one deployed and not the one in that particular workspace.
So assuming
x-script-name is deployed to both namespace-dev and namespace-prod (namespace-dev first)- If I do a
PUTto/workers/dispatch/namespaces/namespace-prod/scripts/x-script-name/secrets - The API hits
/namespaces/namespace-dev/scriptsand notnamespace-prodfor some reason. - I think it hits the namespace that it was deployed to first.
namespace-prod first and add a secret to it and it worked, but deploying the same renamed worker to namespace-dev and trying to add a secret to the last deployed worker it actually ended up added to the namespace-prod one.In other words, the dispatch namespace in this API has no effect it just looks in all the user workers on the account and picks the first one deployed and not the one in that particular workspace.
AI am calling
the handleRequest implementation is just
return await userWorker.handleRequest(request). When i look in the logs, I see that it says "outcome": "cancelled". Any ideas?the handleRequest implementation is just
return new Response('Hello World!');
ISo I believe you're confusing latency and CPU time. 1-2ms would be a reasonable CPU time for a simple JSON worker, and 28-32ms would be a reasonable wall time for that worker. I can't imagine any scenario where a simple JSON worker is using 28-32ms of CPU time per request, that's very high.
I?cpu-time
FCPU Time: the amount of work the CPU needs to do, measured in
Wall Time: the actual amount of time a Worker runs for, as though you measured it with a clock or your browser DevTools
ms. More CPU-heavy things will increase it (for example, hashing passwords). This is not the same as the time a fetch request takes.Wall Time: the actual amount of time a Worker runs for, as though you measured it with a clock or your browser DevTools
IAh OK, I misunderstood then. Just to clarify - you are not billed for ~30ms, you are billed by CPU time.
UWFP has always had some latency to fetch a script
UYes you can and should expect some latency.
W20ms is definitely not normal for any non-cold request
WIf you've got a url I can hit happy to investigate
UThe 20ms is the cold start he said occasionally it will be 0/1ms from the cache
Wit's definitely possible but cold starts are not common for live apps with traffic, we can't keep worker isolates around forever if we get no traffic :p
Wclients won't matter, you will have just hit another colo or something
