secret key in env.local that shows in terminal but not in my browser

[stark harness]

Hey, so I have a utils file where I need to access a private key from my local.env file. So that key is not prefixed with NEXT_PUBLIC because i don't want it to be accessible, when i try to console log it from my utils file, the browser shows undefined, but it shows the correct value in my terminal console.. how can i access this value in my utils file ? thank you very much for any help !

[grand hound]

when i try to console log it from my utils file, the browser shows undefined, but it shows the correct value in my terminal console
if its showing up in the console it means its working, no?

[tribal sail]

Since the terminal is the server console it has access to it

[stark harness]

thanks i solved my issue !

[woeful cargo]

Did you manage to get access to the private key in your util file? I'm fighting this issue right now. I need to use a private key to call an API in a client component

[rare plume]

client component => the browser must be able to access the key => it cannot be secret

[woeful cargo]

What is the appropriate solution? Is it to create a proxy server, or is there something as part of Next 13 I can do here?

[rare plume]

make a route handler that fetches the API with the secret key, then call that route handler from your client component

[woeful cargo]

I will try this. Thank you! 🙂

[woeful cargo]

Update:

Seems like it's bad practice to fetch data from a handler in a client component due to re-renders. Documention mentions using SWR or React Query.

But from what I understand, it is better to abstract interactive elements into separate client components, so the component fetching data can be a server component

I'm new to Next 🙂

[rare plume]

bad practice to fetch data from a handler in a client component due to re-renders
this is incorrect. the re-renders are due to either use(fetch()) or async client components – these are bad practices yes, but fetching handlers with SWR/react-query is not bad practice

But from what I understand, it is better to abstract interactive elements into separate client components, so the component fetching data can be a server component
that's correct. If you can refactor your code in such a way that the fetching component is a server component, then you can (and should) get rid of the route handler and just fetch inside the server component directly (and env vars not having NEXT_PUBLIC will work)