feat(cloudflare): expose event.context.cf

[pi0]

🔗 Linked issue

resolves #391

closes #677

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR exposes cloudflare request context as event.context.cf.

Implementation is based on new unenv support. Any other platform based on localFetch, can expose the same context by passing { context: {} } to the request init.

A new generic handler is added to nitro. It will be used later for other purposes as well.

Note: For nested $fetch, we should explicitly pass the cf to be proxied:

  await $fetch("/test", { context: { cf: event.context.cf } });

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codecov]

Codecov Report

Merging #927 (6f6d0e0) into main (247f312) will not change coverage.
The diff coverage is n/a.

❗ Current head 6f6d0e0 differs from pull request most recent head 14318bd. Consider uploading reports for the commit 14318bd to get more accurate results

@@           Coverage Diff           @@
##             main     #927   +/-   ##
=======================================
  Coverage   67.77%   67.77%           
=======================================
  Files          59       59           
  Lines        5992     5992           
  Branches      679      679           
=======================================
  Hits         4061     4061           
  Misses       1922     1922           
  Partials        9        9           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[altryne]

Is there a way to use this to get bindings from .env?

I saw a screenshot from Atinux about storing state in cloudflare KV workers, so it seems that conceptually that's possible?

But the above exposed request.cf does not include the .env (nor the secrets stored in cloudflare) nor the service, KV, queue bindings.

Is there a way that I'm just missing?

[pi0]

You can use storage layer to store data in KV, Filesystem, memory and anywhere else.

• https://github.com/Atinux/atinotes/blob/ee88ffa8f9dc1d5254ccef10411b815343fdce6a/nuxt.config.ts#L10
• https://github.com/Atinux/atinotes/blob/ee88ffa8f9dc1d5254ccef10411b815343fdce6a/server/api/pages/%5Bslug%5D.get.ts#L5

[dario-piotrowicz]

@altryne you're right you cannot access KVs or other Cloudflare services from what it's exposed, we need to pass the env and ctx to the user as I am doing here for the cloudflare-pages adaptor: #997

After I (hopefully) get the cloudflare-pages adaptor PR merged I can look into adding access to the env and ctx to the cloudflare worker adaptor as well, although in order to do so we'd fist need to convert the adaptor to the ESM syntax as now it uses the old service worker one in which the various variables are just put in the global scope (and some like DO aren't even available).

[altryne]

I actually found a way! it's possible via self.

https://discord.com/channels/473401852243869706/1002541842409193563/1077016381662433372

[dario-piotrowicz]

ah wow, that's interesting! 😮

are you deploying your Nuxt app via the worker adaptor? (not the pages one)
because if you are yeah I do imagine that the bindings are just added to the global scope by Cloudflare so they end up being accessible by self 🤔

[altryne]

Yeah not via the pages one.

[dario-piotrowicz]

ah ok I see, that makes sense, thanks 🙂👍

[altryne]

You can use storage layer to store data in KV, Filesystem, memory and anywhere else.

@pi0 I'm so sorry I missed your comment on this, however, this isn't answering the question of accessing cloudflare bindings on .env.

The storage layer adds storage, however, on the .env, cloudflare is storing the following things that are not storage:

• secrets https://developers.cloudflare.com/workers/platform/environment-variables/#environment-variables-via-wrangler
• Service bindings https://developers.cloudflare.com/workers/runtime-apis/service-bindings/
• Queues https://developers.cloudflare.com/queues/examples/send-errors-to-r2/

All those things are needed when developing a server side application on cloudflare, all their examples aways require to take this information from the request context and I think it would be great to have them, and not have to do hacks like this one:
https://discord.com/channels/473401852243869706/1002541842409193563/1077016381662433372

I think for many worker devs, this would be more important than the context of the IP and country (which is also important)