If you've read my previous blogs then you're aware that I have been learning Next.js recently as I tackle my next project, WatchNext. If you have not read my previous blogs, a quick update for you: I kickstarted a new project to keep the gears in my brain spinning as I search for my first engineering role. During the kickoff process, I quickly encountered an obstacle (I wanted this projet to be frontend only). That obstacle being, how to properly hide my keys on a frontend application without them accidentally being exposed to a client after deployment. Nicholas Papadakis recommended using Next.js and thus my journey to learn it began.
Now that we're caught up let's get to the point of this blog. API KEYS!
The main tidbit of information that I've learned while exploring Next.js is how to keep my secret keys an actual secret. Next.js offers you the ability to create an API directory within your Pages directory. This API directory allows you to create API endpoints for your applications. You can then access these endpoints to get data from your external API as needed. The best thing... everything in it will be private! Including your ENV variables. Seeing as this was my first major obstacle this is a GREAT bonus for me and my current needs.
Using ENV variables is a tad different than how you would implement them on a backend application. To utilize them in Next.js, you will create a file in the highest level of your application and title it .env.local (don't forget to ensure it is included in your .gitignore file so you don't accidentally make it public!). In this file is where you will store your ENV variable like you would normally do in the backend. Now, to access it, you would interpolate it where it's needed and call process.env.ENV_VAR_NAME
/// In .env.local
API_SECRET=PUT_SECRET_HERE
// Whichever file you need to call the ENV variable, within the API directory
const URL = 'https://myapi.org/info?api_key=${process.env.API_SECRET}'
VIOLA!! You have accessed your external API without exposing your precious keys or creating a backend.
If what you've read so far about Next.js sounds like it can be useful to you, I would highly recommend using Next.js for your next project or even migrating a current project that you have to utilize the benefits that Next.js has to offer.
Just a reminder, I am still learning and growing. I am open to any tips and tricks you may have as well as open to answering any questions you may have to the best of my ability. Happy learning!
Resources:
Top comments (7)
I think this new endpoint can still be called from anywhere, maybe consider adding CORS. This will only stop browser calls though. That endpoint may also be susceptible to bots blasting it.
Maybe consider using something like KOR Connect? I have been using them as a middleware tool to secure my API Keys then placing the public URL that's created into my code. This seems to be a 2 birds with one stone kind of situation, as my API secrets are not exposed in my repo nor on my frontend. I find this tool to work really well for my projects where I need to secure a private API Key, don't want user authentication, and want to get it done quickly. They claim to also prevent bot attacks and prevent non origin calls. It's also free, which is a bonus. Here is a blog I found this weekend and followed: dev.to/korconnect/secure-api-keys-...
I found this to help me out a lot so I am putting it up an old blog post, in the hopes that it might help others looking in the future.
Happy coding!
Hi Mary! Thank you for the advice and the blog post to follow! It is greatly appreciated. I'll look into it further!
You said "I wanted this projet to be frontend only" but if you're using the API directory of nextjs it's not frontend only anymore, isn't it ? :)
Be aware that theses env vars are hard coded at build. If you want to build your app once with the possibility to be deployed on different servers with different env vars (ex. one build for production and pre-production) you can use the Runtime Configuration : nextjs.org/docs/api-reference/next...
with static export will be client side only.
Yup! It is in fact what I “wanted” but that isn’t what ended up happening. I see I worded it funky in the blog. Thanks for the tip!
This is just creating a backend that acts as a public proxy to the private API.
That is correct.