(I had the strong suspicion this wouldn't be possible and that I'd have to use WebAssembly instead.
(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?
HDepends. What are you trying to do?
GI'm planning on syncing AWS infra to KV, it should be alright to have autoscaling but in some cases it might be difficult to implement it if it's multiple jobs
GAlways an option to host adaptor myself
HYou could use a Cron trigger to sync it every minute or so
HOr however often you want
GI'm not a fan of Cron. Would rather have reactive arch
HLike, something you trigger yourself?
HThen as long as you wait for it to finish, then there should only ever be one running
GI was thinking of worker subscribing to Kafka. In this particular case there are no issues with autoscaling
GSo I could do Cron Evey millisecond which just syncs until it gets killed 
GAm I getting this right?
Sno
GAnyways, no issues as of right now. And if something comes up I'll either make it scalable or selfhosted
DCan I access a D1 table from a worker on the free plan?
DA binding enables your Pages Functions to interact with resources on the Cloudflare developer platform. Use bindings to integrate your Pages Functions …
