Agreed that this can be confusing - for exactly the reasons that @James shared. Because of the various implementations of environments out there, it's not as clear cut as we'd like - which came up on the Wrangler office hours call today. It would be great to just remove it from the dashboard for the time being, but that could have other unintended effects. I can take a shot at extending the docs to clarify it in the mean time.

Guys, does anyone know how to get environment variables with cloudflare workers outside the fetch context? I'm initializing some stuff before the fetch initializes and I want to get some stuff from the environment variables.

Generally, you can't by design with Module Workers and it's recommended to do things in the request scope. CPU time outside of request scope is extremely limited, since it impacts startup time. You could have a function that takes

env

, call it inside request scope, and then maybe cache the initiated thing on

globalThis

perhaps?

This is my code. I wanted to get the variables up there. If I put it in context it would be a little messed up in my view. I'm trying to use Clean Arch and DDD techniques

If they're not sensitive, you could perhaps use

--define

with placeholders like

TOKEN_URL_HERE

which will replace them as the script is built - see

--define

docs under https://developers.cloudflare.com/workers/wrangler/commands/#publish

But the recommended approach would definitely be to move to the request scope

I'll see the possibility of moving to the fetch context

I really like how environments are organized for Pages. Is there a chance that the future is going to look more like how Pages are done with Production & Preview deployment & bindings?

I'm not on the team so purely speculating, but I would very much assume it'll look like something like that, yes 🙂

One question coming to my mind, maybe off topic. why workers not use nodejs runtime in the beginning. does have own runtime(workerd) can help build other product like kv, R2 etc more easy？

Can't speak for workerd (maybe be worth asking in #1024343493251973190) I believe the biggest reason for using v8 is speed because v8 offer isolates so you can run multiple workers with little overhead. There is also the security benefit because v8 sandboxes the functions https://developers.cloudflare.com/workers/learning/how-workers-works/

Hi everyone! Anyone know how long the waitlist is to get into the

Workers Browser Rendering API

private beta?

On top of what Cyber said, while Node is also built on top of V8, the reason why

workerd

is its own runtime, rather than just Node, is that Node is a very heavy-handed approach to Serverless. Take, for example, AWS Lambda. While it is a Serverless provider, similar to Workers, it runs Node. It’s startup times number in the hundreds of milliseconds, it uses a lot more memory/CPU just for the runtime, etc.

workerd

is lighter, which makes it faster and cheaper, but also means it can’t just support everything a full Node runtime can out of the box

Hi, I'm having issues with some calls getting

outcome: "canceled"

and stopping midway. I need the calls to finish completely even if it gets a cancel signal. Is it possible to configure the workers to finish the work even if a

cancel

signal is sent?

No update yet

No, if the client disconnects before you return a respectonse, the execution ends

Greetings, from few days I am getting an authentication err (see attachment) when I run command

wrangler dev --minify true --env staging

if I add -- local flag i.e` wrangler dev --local --minify true --env staging` its working perfectly, any idea ?

Could you try

wrangler logout

and

wrangler login

again?

already tried but its not working

Could you go to

node_modules/.cache/wrangler

and delete everything there?

Would really need this at work for an upcoming project. Guess we'll have to look elsewhere.

Any possible way to run workers on query url?

what is query url?

Inconvenient when an add is clicked, like Google ?GCLID - all of a sudden all worker scripts dont fire...

You can't match workers based on wehther there's a query parameter or not, if they're on that route, they'll always run

It sounds instead like there might be a problem with your code, or the route not being set up correctly, but you've not given much information to go on

Workers will break ?ajax/etc on Wordpress - therefore the worker has been set to run on /a*, /b*, /c* etc

Which of course has disabled the query url