Env Vars on Pages anyway **are** coupled to a deployment. For example, if you change vars in the das

HHello, I’m Allie!Env Vars on Pages anyway **are** coupled to a deployment. For example, if you ch...

R

Rich•9/27/23, 10:14 AM

I did wonder this, but given they're defined on

context.env

context.env

which is bound to a request figured they must change dynamically?

Otherwise I'd love to just have them on

global.env

global.env

global.env

global.env so I don't have to pass them around to various modules all the time.

R

Rich•9/27/23, 10:14 AM

If we were to update the env vars via the API in our build script, there'd be a race condition between deploys I expect, it'd need to be passed in as part of the wrangler deploy cmd I expect and not impact other deployments?

K

kian•9/27/23, 10:16 AM

I did wonder this, but given they're defined on context.env which is bound to a request figured they must change dynamically?

context.env

context.env

is a Pages/Functions wrapper over the

fetch(req, env, ctx)

fetch(req, env, ctx)

that all Workers use. Your resulting built Worker will use

export default { async fetch(...) }

export default { async fetch(...) }

.

K

kian•9/27/23, 10:17 AM

Otherwise I'd love to just have them on global.env so I don't have to pass them around to various modules all the time.

AsyncLocalStorage is a nicer way to do this, but this is fine. If you use it for arbitrary per-request things (i.e doing

globalThis.reqId = "123"

globalThis.reqId = "123"

then other requests will be able to see and mutate that.

K

kian•9/27/23, 10:17 AM

If we were to update the env vars via the API in our build script, there'd be a race condition between deploys I expect, it'd need to be passed in as part of the wrangler deploy cmd I expect and not impact other deployments?

wrangler deploy

wrangler deploy

has no way to do this, unfortunately. It is all done in the dashboard/API.

K

kian•9/27/23, 10:18 AM

It does seem a shame CF Pages doesn't let you define a deployment-level env var.... I guess it's because env vars are request-level in workers so perhaps not coupled to a deployment.

Changing variables doesn't do anything until you do a new deployment, which is a new Worker.

K

kian•9/27/23, 10:18 AM

A given deployment will always have the same variables.

Kkian > I did wonder this, but given they're defined on context.env which is bound to ...

R

Rich•9/27/23, 10:30 AM

Interesting, I did briefly look at

AsyncLocalStorage

AsyncLocalStorage

but felt it was a bit complex / overkill, just wanted to shove it on

globalThis

globalThis

:

export const onRequest = async (
  requestContext: EventContext<any, any, any>
): Promise<Response> => {
   globalThis.env = requestContext.env;
   handleRequest(requestContext.request);
}

export const onRequest = async (
  requestContext: EventContext<any, any, any>
): Promise<Response> => {
   globalThis.env = requestContext.env;
   handleRequest(requestContext.request);
}

export const onRequest = async (
  requestContext: EventContext<any, any, any>
): Promise<Response> => {
   globalThis.env = requestContext.env;
   handleRequest(requestContext.request);
}

export const onRequest = async (
  requestContext: EventContext<any, any, any>
): Promise<Response> => {
   globalThis.env = requestContext.env;
   handleRequest(requestContext.request);
}

However these docs (https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#parameters) made me nervous as it says:

env
The bindings assigned to the Worker. As long as the environment has not changed, the same object (equal by identity) is passed to all requests.

But maybe bindings != env vars? (tbh I think I have a bit of a knowledge gap given my first usage of Workers is through Pages)

Fetch Handler · Cloudflare Workers docs

Incoming HTTP requests to a Worker are passed to the fetch() handler as a request object. To respond to the request with a response, return a Response …

K

kian•9/27/23, 10:30 AM

Bindings are env vars

K

kian•9/27/23, 10:30 AM

Those docs are for Workers, a given Worker

K

kian•9/27/23, 10:30 AM

Pages Functions are a different Worker per deployment

K

kian•9/27/23, 10:30 AM

One cannot affect the other

K

kian•9/27/23, 10:31 AM

Section 1 on this issue might help you visualise it in the context of Pages

https://github.com/cloudflare/next-on-pages/issues/1#issuecomment-1403845325

K

kian•9/27/23, 10:31 AM

We were hesitant to add this on day 1 because we re-use isolates as a performance optimization wherever possible. This means that as we process one request with set of environment bindings, another request also start to be processed, potentially with a different set of environment bindings. In the typical Cloudflare Worker written in ESM format, this isn't an issue since the request and env come in together. However, if you were to access the environment from a global scope like Next.js does, there's a risk that the new set of environment bindings will override the previous set as that previous request is still processing.

To be clear, we do not share isolates across accounts (or even, across different Workers), so there's never as risk of your environment leaking across accounts or projects. Instead, if you updated your environment variables of your project as it served live traffic, we were concerned that potentially some requests would be 'polluted' with the newer set of environment variables as they were still being processed.

It turns out, that after some investigation, the way that Pages does deployments means that this won't happen anyway. It took us some time to confirm this, but we're now confident that there will be no accidental 'leakage' of environment bindings across deployments.

K

kian•9/27/23, 10:33 AM

In the context of Workers, you can have a single Worker that has two requests with a different

env

env

if you change the bindings.

In the context of Functions, with the way that a given deployment can't have the bindings changed, it's irrelevant.

K

kian•9/27/23, 10:33 AM

Treat two Pages deployments as entirely separate Workers, basically.

K

kian•9/27/23, 10:35 AM

That first paragraph, as a bit of trivia, is why Module Workers are faster than Service Workers. They don't need a global scope to be bootstrapped on every request.

K

kian•9/27/23, 10:39 AM

In the case of AsyncLocalStorage, it's like this

import { AsyncLocalStorage } from "node:async-hooks";

const asyncLocalStorage = new AsyncLocalStorage();

export const onRequest = async (
  requestContext: EventContext<any, any, any>,
): Promise<Response> => {
  return asyncLocalStorage.run(requestContext, () => {
    return handleRequest();
  });
};

function handleRequest() {
  const requestContext = asyncLocalStorage.getStore();
  const req = requestContext.request;
  await requestContext.env.KV.put("foo", "bar");
}

import { AsyncLocalStorage } from "node:async-hooks";

const asyncLocalStorage = new AsyncLocalStorage();

export const onRequest = async (
  requestContext: EventContext<any, any, any>,
): Promise<Response> => {
  return asyncLocalStorage.run(requestContext, () => {
    return handleRequest();
  });
};

function handleRequest() {
  const requestContext = asyncLocalStorage.getStore();
  const req = requestContext.request;
  await requestContext.env.KV.put("foo", "bar");
}

import { AsyncLocalStorage } from "node:async-hooks";

const asyncLocalStorage = new AsyncLocalStorage();

export const onRequest = async (
  requestContext: EventContext<any, any, any>,
): Promise<Response> => {
  return asyncLocalStorage.run(requestContext, () => {
    return handleRequest();
  });
};

function handleRequest() {
  const requestContext = asyncLocalStorage.getStore();
  const req = requestContext.request;
  await requestContext.env.KV.put("foo", "bar");
}

import { AsyncLocalStorage } from "node:async-hooks";

const asyncLocalStorage = new AsyncLocalStorage();

export const onRequest = async (
  requestContext: EventContext<any, any, any>,
): Promise<Response> => {
  return asyncLocalStorage.run(requestContext, () => {
    return handleRequest();
  });
};

function handleRequest() {
  const requestContext = asyncLocalStorage.getStore();
  const req = requestContext.request;
  await requestContext.env.KV.put("foo", "bar");
}

K

kian•9/27/23, 10:42 AM

Eventually, you might be able to just do this instead

import getRequestContext from 'cloudflare:request-context';

const [ req, env, ctx ] = getRequestContext();

import getRequestContext from 'cloudflare:request-context';

const [ req, env, ctx ] = getRequestContext();

import getRequestContext from 'cloudflare:request-context';

const [ req, env, ctx ] = getRequestContext();

import getRequestContext from 'cloudflare:request-context';

const [ req, env, ctx ] = getRequestContext();

https://github.com/cloudflare/workerd/pull/1213

R

Rich•9/27/23, 10:45 AM

Ok interesting. So sounds like it'd be totally safe to add env to

globalThis

globalThis

within CF Pages Functions (but not CF Workers). But maybe if

AsyncLocalStorage

AsyncLocalStorage

is as simple as above, I might try that as would be super handy to access the req too.

K

kian•9/27/23, 10:45 AM

Yep.

K

kian•9/27/23, 10:46 AM

If you want to use

AsyncLocalStorage

AsyncLocalStorage

(as well as other

node:

node:

modules) then add the

nodejs_compat

nodejs_compat

compatibility flag to your Pages project.

https://developers.cloudflare.com/workers/runtime-apis/nodejs/

R

Rich•9/27/23, 10:46 AM

Do you know if there's much of a performance cost for using AsyncLocalStorage?

K

kian•9/27/23, 10:47 AM

I've never benchmarked it personally. You could do your own benchmark for it, but I doubt it's much of an issue.

It'd only be worth looking at it in terms of time (i.e <x>ms slower) since rps is irrelevant with a distributed application like Workers/Functions.

K

kian•9/27/23, 10:48 AM

If you do it with

pages dev

pages dev

then it'll use

workerd

workerd

locally so you can just hammer that without having to worry about network latency/etc.

R

Rich•9/27/23, 10:52 AM

Good to know, will do some tests if I choose to use it a lot. Thanks for all the insight, super valuable!

HHello, I’m Allie!Env Vars on Pages anyway **are** coupled to a deployment. For example, if you ch...

R

Rich•9/27/23, 11:24 AM

So it turns out there are some predefined runtime env vars which seem to be available even for direct uploads -- I'm guessing they're read from the deployment metadata:

console.log(">", requestContext.env.CF_PAGES);
console.log(">>", requestContext.env.CF_PAGES_COMMIT_SHA); // 🙌
console.log(">>>", requestContext.env.CF_PAGES_BRANCH); // 🙌
console.log(">>>>", requestContext.env.CF_PAGES_URL);

console.log(">", requestContext.env.CF_PAGES);
console.log(">>", requestContext.env.CF_PAGES_COMMIT_SHA); // 🙌
console.log(">>>", requestContext.env.CF_PAGES_BRANCH); // 🙌
console.log(">>>>", requestContext.env.CF_PAGES_URL);

console.log(">", requestContext.env.CF_PAGES);
console.log(">>", requestContext.env.CF_PAGES_COMMIT_SHA); // 🙌
console.log(">>>", requestContext.env.CF_PAGES_BRANCH); // 🙌
console.log(">>>>", requestContext.env.CF_PAGES_URL);

console.log(">", requestContext.env.CF_PAGES);
console.log(">>", requestContext.env.CF_PAGES_COMMIT_SHA); // 🙌
console.log(">>>", requestContext.env.CF_PAGES_BRANCH); // 🙌
console.log(">>>>", requestContext.env.CF_PAGES_URL);

// deployment
"deployment_trigger": {
  "type": "ad_hoc",
  "metadata": {
    "branch": "feature/foo",
    "commit_hash": "48e8ab8181e00008140866a28ffaa16e7a99161",
    "commit_message": "Add foo",
    "commit_dirty": false
  }
},

// deployment
"deployment_trigger": {
  "type": "ad_hoc",
  "metadata": {
    "branch": "feature/foo",
    "commit_hash": "48e8ab8181e00008140866a28ffaa16e7a99161",
    "commit_message": "Add foo",
    "commit_dirty": false
  }
},

// deployment
"deployment_trigger": {
  "type": "ad_hoc",
  "metadata": {
    "branch": "feature/foo",
    "commit_hash": "48e8ab8181e00008140866a28ffaa16e7a99161",
    "commit_message": "Add foo",
    "commit_dirty": false
  }
},

// deployment
"deployment_trigger": {
  "type": "ad_hoc",
  "metadata": {
    "branch": "feature/foo",
    "commit_hash": "48e8ab8181e00008140866a28ffaa16e7a99161",
    "commit_message": "Add foo",
    "commit_dirty": false
  }
},

C

CEbbinghaus•9/27/23, 11:27 AM

So I have a bit of a problem. Friend of mine can't get the cloudflare pages runenr to work. It exists with an error message about the functions not being able to be uploaded but the site doesn't contain any functions. No functions directory nor a

_worker.js

_worker.js

file. I am really confused what could be causing it to try and push functions for a directory that doesn't contain any

CCEbbinghaus So I have a bit of a problem. Friend of mine can't get the cloudflare pages rune...

I

Isaac McFadyen•9/27/23, 11:29 AM

Is it a SvelteKit, Remix, Nuxt, or Next.JS site?

I

Isaac McFadyen•9/27/23, 11:29 AM

Or Astro?

C

CEbbinghaus•9/27/23, 11:29 AM

Whoops good point. Its Astro

C

CEbbinghaus•9/27/23, 11:30 AM

non SSR

I

Isaac McFadyen•9/27/23, 11:30 AM

Non-SSR. Hmm... OK. So I would normally have assumed that was the reason but if it's non-SSR then it shouldn't be creating any functions.

I

Isaac McFadyen•9/27/23, 11:30 AM

If you run a build locally does a functions folder or _worker.js get created?

RRich So it turns out there are some predefined runtime env vars which seem to be avai...

K

kian•9/27/23, 11:31 AM

They're all taken from

git

git

in the folder of the direct upload, or passed by CLI to

pages deploy

pages deploy

https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/pages/deploy.tsx#L219-L238

IIsaac McFadyen If you run a build locally does a functions folder or _worker.js get created?

C

CEbbinghaus•9/27/23, 11:31 AM

Nope

C

CEbbinghaus•9/27/23, 11:32 AM

neither does the server run. I checked the uploaded artifacts and it didn't show there

I

Isaac McFadyen•9/27/23, 11:32 AM

Hmm... interesting. Can you give the exact error message if you have it?

IIsaac McFadyen Hmm... interesting. Can you give the exact error message if you have it?

C

CEbbinghaus•9/27/23, 11:32 AM

Yup, Friend just joined server. Gimme sec

I

itsanobrain•9/27/23, 11:32 AM

hi

C

CEbbinghaus•9/27/23, 11:32 AM

^frien

I

itsanobrain•9/27/23, 11:33 AM

Screen_Shot_2023-09-27_at_9.33.15_pm.png

I

Isaac McFadyen•9/27/23, 11:34 AM

Hmm. Interesting. It definitely doesn't see Functions because of the first message but the second seems to contradict it.

I

Isaac McFadyen•9/27/23, 11:34 AM

Can you give the deployment ID? It's the UUID in the URL.

I

itsanobrain•9/27/23, 11:34 AM

Screen_Shot_2023-09-27_at_9.34.17_pm.png

I

Isaac McFadyen•9/27/23, 11:34 AM

As well as the pages.dev if you have it.

I

itsanobrain•9/27/23, 11:34 AM

vl is final folder

I

itsanobrain•9/27/23, 11:35 AM

deployment ID: a2450de6-55d9-460e-b794-9da3f0e1bef7

IIsaac McFadyen As well as the pages.dev if you have it.

C

CEbbinghaus•9/27/23, 11:35 AM

?

CCEbbinghaus ?

I

Isaac McFadyen•9/27/23, 11:36 AM

It's the

<domain>.pages.dev

<domain>.pages.dev

that your website was assigned. Usually it's visible on the Pages project page.

Env Vars on Pages anyway are coupled to a deployment. For example, if you change vars in the das

Similar Threads

Similar Threads

Similar Threads