Chi, I am new to cloudflare workers....I need code to connect D1 database to workers.
have tried this code
export async function onRequest(context) {
// Create a prepared statement with our query
const ps = context.env.NORTHWIND_DB.prepare('SELECT * from users');
const data = await ps.first();
return Response.json(data);
}
but didnt know how to add NORTHWIND_DB as database connection variable. Can anyone please help
have tried this code
export async function onRequest(context) {
// Create a prepared statement with our query
const ps = context.env.NORTHWIND_DB.prepare('SELECT * from users');
const data = await ps.first();
return Response.json(data);
}
but didnt know how to add NORTHWIND_DB as database connection variable. Can anyone please help
CAre there any other tips for troubleshooting
I have a small small script:
And it does almost no initialization at startup, but I cannot deploy it.
"Error: Script startup exceeded CPU time limit."?I have a small small script:
Total Upload: 388.83 KiB / gzip: 91.02 KiBAnd it does almost no initialization at startup, but I cannot deploy it.
WYou do any imports?
WWhat have you got in the global scope?
Cyeah, a few imports, just saw a note to move those into the handler, and the first one I moved got me over the hump and I can now deploy
Uif you dont have a head function then yes it would be normal
TI'm migrating an existing worker from service worker to ES module format. Not a huge deal, with one caveat. Before I was accessing environment variables as globals, now they're are in the environment object. Are people just plumbing that environment object through layers of their code or is there a more elegant way to handle things? I'm finding myself adding
env to a large quanity of my functions just to get access to things where I need them.
HYou can use https://developers.cloudflare.com/workers/runtime-apis/nodejs/asynclocalstorage to plumb variables out around your Worker.
Cloudflare Workers provides an implemenation of a subset of the Node.js AsyncLocalStorage API for creating in-memory stores that remain coherent …
TI see. So I could create an asynchronous context at the top of my fetch handler, pass my environment into it, then gain access to that anywhere in the following asynch code. That's nice.
JHow can I know the CPU architecture and OS platform my workers are running on? In node.js I'd use either
At most, with
process.arch and process.platform, or os.arch() and os.machine(). However, there are no such options for CF Workers. At most, with
node_compat = true, I get os.arch() === "javascript" and process.platform === browser
CWhy do you need to know the architecture and OS? That stuff shouldn’t matter in the code
JI'd like to try importing a native addon (which is platform dependent) into a Cloudflare Worker. The addon would be built with napi.rs
CI don’t believe worker code runs low enough where stuff like arch is accessible. All code runs in workerd which is V8 engine
J(I had the strong suspicion this wouldn't be possible and that I'd have to use WebAssembly instead. I'm just asking here to get confirmation)
HYou don't get to run native anything on Workers. It's either WASM, or JS.
TIs it dumb to run WebAssembly inside a JavaScript worker? I have some shared code in WebAssembly that I'm running in many runtimes, it would be nice to run that inside my existing JavaScript worker
TI'm sure there is some overhead for invoking the WebAssembly runtime. Right now my worker takes about 2ms of CPU time. The algorithm is pretty trivial and already in my JavaScript worker. I just want to replace it with the WebAssembly version so I don't have to maintain this algorithm in multiple languages. Any idea how much overhead the WebAssembly runtime has?
IThe main reason WASM takes longer is that there is no runtime, really (I mean there is but not really). By that I mean if you write some code in Go, or Rust, etc, then the entire garbage collector or standard library has to be shipped with the WASM, which means it takes much longer to boot.
IVersus JavaScript, which can be run directly on a V8 isolate, meaning scripts share the garbage collector etc (isolated in isolates but more shared than WASM)
IPretty much the only way to know is to benchmark yourself with your specific WASM code.
TMy hope was to actually invoke my WebAssembly from inside a JS worker. I'm realizing now this might not be possible? I'm not seeing WebAssembly as part of the Worker runtime. Is that right?
TLooks like v8 supports it, but not sure about the CF version
HIt does. That’s how #
workers-rs works
workers-rs worksTGreat. I'm just getting into it. I rewrote my algorithm in AssemblyScript and compiled to WASM. I'm just about to start trying to use it in my Worker.
JToday I've verified that this is possible!
TAwesome 
JI noticed today that req.url seems to be defined to be relative to the routes in your wrangler config, even when you are developing locally.
This has issues when developing locally with libraries like next-auth, since they use the req.url to generate the callback urls.
I'm wondering if anyone here would know of a reason for it to be this way?
This has issues when developing locally with libraries like next-auth, since they use the req.url to generate the callback urls.
I'm wondering if anyone here would know of a reason for it to be this way?
Gtry with
--host 127.0.0.1:8787 though it won't work with --remoteJThat does seem to resolve the issue!
It would still be good to understand why/if this is actually needed if anyone had ideas.
It would still be good to understand why/if this is actually needed if anyone had ideas.
Gdoes anyone know if cloudflare reserves short subdomains for services like workers? (also zero trust seems to have no subdomains available unless you got 3+ chars)
SHas anyone done some load testing with k6 on Workers?
Basic stuff runs without hitch, but trying to test e.g. a 1000 simultaneous users/requests gives a bunch of timeouts, though as far as I understand Workers itself should be able to handle that no problem. Makes me think that perhaps the requests are getting blocked/throttled by Cloudflare.
Basic stuff runs without hitch, but trying to test e.g. a 1000 simultaneous users/requests gives a bunch of timeouts, though as far as I understand Workers itself should be able to handle that no problem. Makes me think that perhaps the requests are getting blocked/throttled by Cloudflare.
NHey guys, there's any way to do a similar deploy flow from pages to workers, like, in each commit the worker publishes/deploys itself?
CHey, can anyone help me to connect D1 database to worker...have checked the document also but I was doing it wrong somewhere. Can you please provide sample code for this.
CAs I am new to this cloudflare workers and wrangler ... don't know to integerate .
Pare there any tips for including packages in a JS worker that include wasm? It looks like the worker build is generating a
wasm2.__wbindgen_start() line in the bundled js, but the worker claims it can't find it even though it's a function in the bundled wasm file
Bi am encountering a 403 error when accessing the workers endpoint through a deployed web ui, but its working in my localhost. Did I missed something
JI'd like to hear a Cloudflare devs's opinion on this PR for wasm-bindgen to avoid the "JavaScript Plumbing" step currently needed in JS+Wasm workers: https://github.com/rustwasm/wasm-bindgen/pull/3510.
Hopefully the PR's description, comments, and clarifications are easy to understand
Hopefully the PR's description, comments, and clarifications are easy to understand
TCan confirm. I just setup toucan-js in my ES module project. Works great.
TEnded up being pretty simple:
Gis it possible to have a single worker without autoscaling?
CThere isn’t but why would you want that?