Do I need to do something like

npx wrangler <download copy of KV=TEST_DB to my local machine so I can test it>

command first?

Also. And this is a suggestion. What if the wrangler build script that compiles and sets up the worker, printed out its full command? This would be really nice and useful to see. Or. Even better. If it printed out the complete command for testing locally with the same settings for KV and DO and VARS? This would be a one stop shop for lots of slightly more advanced documentation needs.

I tried to rename the functions variable to also be

TEST

so that there would be no difference between the two. Still

null

locally. When I

console.log(env.TEST)

locally, i get

KVNameSpace {}

. It works fine up on the server.

As I said, there is no syncing between local and production

ok. and then i need to make a local copy and then fill it with some test data?

When you put

--kv TEST

in your command (or whatever you call your namespace), it creates a local version in your filesystem which has no initial data

I believe it only actually shows up after you store something in it though

thanks) I finally have something! Hehehe😅 My first instinct (mayor exaggeration;) was to run

npx wrangler kv:namespace

and then

kv:put

commands. Which worked after a little while. Worked on the server that is (which i don't need). But not locally (which i do need). Ok. Delete that. Move on. Second attempt was.. should I make a custom worker that will fill the table with some startup data? And that worked. That created the

.mf>kv>TEST

folder with "hello" file with the content "world". and a "hello.meta.json" too, just to test. So. My final question is. To create a local KV store for local test purposes, should I just create these files manually? So that I have something to read?

So thanks for the tip with the local version of the KV, @Skye😀

If you're just using a small amount of data, you may as well just manually create the files, yes

If you need a bit more, it may be useful to setup a route that fills it for you? (you could get this to 404 or whatever in production)

Is Pages functions Workers Request count separated from the main Workers Request count? Or they will be merged at the end?

Is there a solution / workaround to the CORS issues on Cloudflare Functions? I'm trying

const req = await fetch('https://api.sendgrid.com/v3/mail/send', {
      method: 'POST', ...

which fails with a CORS error 😦

You can make a CORS proxy in a Worker - https://developers.cloudflare.com/workers/examples/cors-header-proxy/

Probably adapt that for Functions too if you wanted

so I need a worker to proxy a function to send an email?

Functions are in beta right now, so that 100k limit is maximum (seperate from Workers). You can't pay more to get more Functions requests but you can request a quota increase here: https://docs.google.com/forms/d/e/1FAIpQLSe4N0BjIxu9AuissCAtYjXUovViXmdx2zopjzASaJi_SImJsw/viewform?usp=send_form

Once Functions hit GA, then they will be billed similar to Workers.

Is there any estimate when compatibility_date will be added to pages/functions? 🙂

I don't know how you would best do it, but 1. in pages/settings/functions: a "compatibility_date": <input type=text pattern="\d{4}-\d\d{1,2}-\d{1,2}" 2. wrangler pages dev --compatibility_date="2021-12-24" would fit the rest of the api in my mind. If it is weeks away, I would probably need to implement some shortlived bypass... That feels sad... If it is days away, that would be like christmas:) Hours you said??! No, no, that would be too good to be true!! 😄

oops, mistake with KV

I was replying to your message and it disappeared before my eyes

Do functions not support secrets? All I see are plaintext env variables

No secret support today unfortunately, but I know it's on the todo list

That's a bummer, but oh well

Thanks for the answer!

cant u use KV for it in theory?

not the most secure thing ever, but secure enough

was just dumb, wrong var name, always the coders fault