How can I trigger a cloudflare worker from a non-cloudflare backend? Can I enqueue a message from a
How can I trigger a cloudflare worker from a non-cloudflare backend? Can I enqueue a message from a non cloudflare worker as well?
HJust send an HTTP request?
BIn that scenario, I would be responsible for creating my own means of authenticating the request.
BBut gotcha. I guess I was just wondering if there was a client library of some sort or not
HNot really, because any HTTP(S) request hitting a route covered by a Worker will run said Worker
HThere isn’t really anything there for the library to do
HAt least not with just a regular Worker
HIf you are running a GraphQL server on Workers, then there are a few libs to choose from there
AHey folks, here's something that kept me up all night: I'm making a request to a db running on my server from within a worker. Running it locally works fine, but fails once it's deployed. I've been looking at the access logs on the server and the requests coming from the deployed worker seem off:
(worker on CF):
(worker running locally):
I notice that all the requests initiated from the deployed worker (even those with a body etc) all have only
(worker on CF):
"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms(worker running locally):
"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1msI notice that all the requests initiated from the deployed worker (even those with a body etc) all have only
19 bytes request size. It's a long shot, but what are your thoughts on that?
KAre you fetching an IP and/or on a non-standard port?
KIf not, would need to see what the
fetch code looks likeAJust your vanilla fetch:
AI already had the thought that it could have something to do with maybe certificates, but I guess then the request would fail in a different way?
AThe thing that throws me off is that my reverse proxy (traefik) is the one returning the 404, it doesn't seem to be able to route it to the right docker container. So it's either an issue with the rev. proxy (traefik), or it's an issue with the request itself (cloudflare)
AOkay, just deployed a minimal example, and here the requests are fine (result and server logs). Must be something with the deployment config of the other worker.
AUpdate: It's a Cloudflare issue with custom domains. As soon as I add
route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" } to my wrangler config, the requests fail. Any pointers to how my config is wrong?KIs the Worker you're fetching from also on
textmait.se?KSame-zone subrequests are, uh, annoying
AYup,
db-dev.textmait.se is an A record pointing to my server, api2.textmait.se is managed by CF to point to the worker.KAdd
to your wrangler.toml
to your wrangler.toml
Kyou can track that issue to know when you can remove the compatibility flag
AThank you! What exactly does this do? Because I'm not seeing any changes after deploying with it
KNo idea - it's just what the Workers team recommend in that linked issue which supposedly fixes the same-zone subrequests
AHuh, okay. Tbh, never heard about same-zone subrequests until now, so I'll keep that in mind. I've at least now have our service back and running by using the .workers.dev domain, so thank you very much for pointing me into the right direction!
KHistorically, a Worker on
foo.com has never been able to fetch anything else on foo.comKUsing a custom domain (rather than a route) allowed it to fetch other things on
foo.comKbut then
minimal_subrequests (default as of 2022-04-05) broke thatAWow that's fascinating. I think I wouldn't have been able to figure that out by myself
AWorst case I gotta buy a second domain for the api 
KIt really should just work - comment on https://github.com/cloudflare/workers-sdk/issues/2659 that it's still broken for you and the team might have other suggestions
KThat issue is more for Worker <-> Worker so there might be another bug for your Worker <-> Proxied Origin scenario
AThank you, I'll do that!
Phey so idk if this is the right place for it please redirect me to the appropriate person if needed. I noticed the WASM Runtime is public under the
workerd package on NPM. I happen to hold the workered (with the 'e') package name but its not doing much and I don't need it. So I can release it if Cloudflare can put that to better use?PAsking so that if you need it and I do it on the wrong time someone else would probably take it up lol
KCloudflare doesn’t hold a trademark for workerd but I can see how that package name could be used maliciously for typos - cc @veerooo who can get the message to the right people
JFunctionally that code will work, but you won't really get the benefit of cache when you're combining scheduled workers + real traffic.
Your better option here would probably be to store the info to KV on that schedule instead - that provides much more of a guarantee, and will be quick to retrieve.
cache is datacenter specific, and scheduled workers run in a subset of datacenters, so if you get traffic in a datacenter that your schedule didn't run in, it won't have a cache. And if that only runs once per hour for example, it's only cached in 1 location.Your better option here would probably be to store the info to KV on that schedule instead - that provides much more of a guarantee, and will be quick to retrieve.
CYou can't run express.js on workers. Workers uses the V8 run time not Node JS
Crailway or fly.io are going to be your best bets
