R2 <> NextJS
I can get the bucket configured to my proccess.env however it says all the objects are empty. Also, the bucket is working on my production build.
5 Replies
By this do you mean that you can see your objects but they’re zero-length?
No the object appears as R2Bucket {},
in the command line.
I can see some options, like
objects: {} inside of it
Are you trying to console.log the binding? That will not give you a list of objects FWIW if that’s what you’re expecting. You’ll want to console.log the result of BINDING.list()
okay that's good to know. I've been trying
const obj = await process.env.CRYPTO_NOTIFICATIONS.get('gainers.csv'); which works on my production branch and wasn't working locally, so I tried console logging the process.env.CRYPTO_NOTIFICATIONS
This seems to work when i run the wrangler on the production build
but then this code triggers, so the env avraible is there but the object is null
If i define my bindings in my wrangler.toml do I have to run the command with --r2=BUCKET ?
and is --local needed?Okay so your
--local bucket and your production bucket are separate
--local uses Miniflare, so if you upload to a bucket when --local is set, you're only uploading to a faked version of your bucket. This is useful for development.
In general, this is how you should set things up:
1. Set up a CRYPTO_NOTIFICATIONS binding in your wrangler.toml that is a R2 bucket. (Like this: https://developers.cloudflare.com/r2/api/workers/workers-api-usage/)
2. Run wrangler dev (or whatever Next's equivalent is) when you want to develop.
3. Wrangler has two modes of development: you can either work completely offline (using --local), or you can set things up so that during wrangler dev, you talk to a different bucket and after deployment you talk to a different one. (so like a staging / production environment)
4. By default, Wrangler runs in the second "mode", so it will ask you set a preview_bucket_name in your wrangler.toml. It will use this bucket during development (your development/staging environment), and the bucket_name will be used after you deploy (your production environment).
5. Now you can do your thing, build features etc. and you'll notice that your app will upload things to your preview bucket.
6. Once you deploy (wrangler publish or whatever you do for Next), your app will talk to your production bucket.
7. If for some reason you want to work completely locally, you'll use the --local flag. Now of course since this is local, it cannot talk to an actual bucket, so Wrangler uses Miniflare to fake the Worker environment, and in turn, fakes a bucket binding as well. This means of course that anything you upload here won't show up in any bucket.
All through this, your app doesn't need to change at all. Wrangler will talk to different buckets (whether preview_bucket_name or a fake Miniflare one, and will populate CRYPTO_NOTIFICATIONS appropriately)
FWIW the #wrangler channel might also be useful if you're new to Workers and Wrangler!@
In fact, asking there might be good idea anyway because I'm not too familiar with Next and how Wrangler interacts with it (and I might be confusing you more)
It's also worth noting that process.env is a Node thing, and won't work in a Workers environment. You'll want to get your bucket binding (CRYPTO_NOTIFICATIONS) from the env variable in your Worker's fetch handler