Hasty Treat - Environmental Variables

Welcome to Syntax in this Monday.

Hey, Streat. We're gonna be talking all about our environment, Variables.

These are the variables that you use that are often kept as secrets or maybe they're just some of the variable information That sticks along with the different aspects of how your application is running, different environments, so to say. My name is Scott Talinski. I'm a full stack developer from Denver, Colorado. And with me, as always, is Wes Bosch.

The variable master, They call me in high school. The variable master.

Variable master disaster getting it faster. Blaster. Okay. Oh, that's good. Yeah. Oh, yeah.

Okay. This episode is sponsored by 2 of our favorite sponsors over here at Syntax, and that is Sanity and Sentry. Do you wanna Digging a little deep on on Sanity and I'll take Century, Wes. Yes. Sanity

dot I o is the structured content CMS.

They always check change their tagline. I love it on their their home page. You can tell they're constantly tweaking the marketing as well as the actual product. See the magic? Yeah. The magic is build beyond your expectation.

Sanity is the ultimate content platform that helps teams dream big and deliver quickly.

They've got Nike, and Fig Figma is running on Sanity. That's pretty cool. Movember, Conde Nast, Cloudflare. Basically, what it is is It's a a CMS. You configure it in your code. So what your CMS is can be kept in Git, And then you deploy this thing, and you can either host yourself or use Sanity to host it, the back end. This thing is called Sanity Studio, And its entire back end written in React. And if you want to, you can make your own inputs and make your own customization. So It's kind of the best of both worlds because it's a hosted service. It comes with all this amazing stuff out of the box where you can have custom work flows and custom inputs and everything you could imagine. But then if you if you really want to, you can make your own inputs and make your own workflows and and whatnot. So, like, this really is the best of both worlds. So check it out, sanity.i0forward/syntax.

It's gonna get you double the free usage tier. And tweet us what you're making with Sanity. We've had a couple people do that lately, and it's kinda cool to see what people have built on it. Sick. This episode is also sponsored by Sentry, and that's at Sentry dot I o. Now Sentry is the perfect place to track all of your errors and exceptions.

We love Sentry over here at LevelUp Tutorials and Syntax. That's what I use it on my platform, LevelUp Tutorials.

And I absolutely could not exist without Sentry. Sentry is the tool that allows me to push with confidence when I know that if there is a major issue you going on on the site. I'm going to notice it very quickly because all of my errors and exceptions are logged, cataloged, organized, and even displayed blade in terms of the frequency and when they last hit and if it was a regression and a GitHub issue attached to it and all sorts of amazing stuff that you want out of an error and exception handling service. It also tracks performance metrics as well, which is something that we definitely love and use. Using the latest, you can see exactly how fast all of your routes on your entire page are loading because as your users are hitting your site, It's sending some of that information to Sentry. It's almost like analytics for performance. It's fantastic.

Love it. Love it. Love it. So head on over to Sentry dot I o. Use the coupon code tasty treat, all lowercase, all one word, and you're gonna get 2 months for free of that sweet, sweet Sentry error and exception handling service. Cool. So e and v variables.

E and v variables are one thing that can be a giant PIA, and you've been doing A little bit of a a deep dive and digging in here. So I'm interested to talk to you about some of your strategies and some of your ideas here because we we've recently Redone how we're doing all of our environment variables ourselves, and it's a world. Let's just say that. Yeah. Totally. So what are environmental variables?

Environmental variables are variables that are set on The machine that is running your code, and they are often things that are secret. So these are variables that cannot go in your code Because they are sensitive in nature and or they change depending on the environment in which they're running in. So Things like API keys, IDs for OAuth, database URLs, where your database is hosted, node environment. All these things are variables that are based on which environment is it running in. So what are different environments? Well, you have, like, development when you're running it locally on your machine. You probably wanna connect to some sort of test database, and then you push that thing up and you make a pull request, and then you build a preview of that. Maybe that's like a A staging environment that you might have a couple different variables for that. And then when you go to production, there's a whole new set of of environmental variables. So These are values that are set on your machine or set via your host. Your host will usually give you some sort of UI to set them. And then when you run your code, you access them. Usually, it depends on which language you're using, but every language out there uses these. They're available at process.env, and this is specifically Node and JavaScript.

Process.env.

Whatever it is, database underscore URL dot GitHub underscore API key dot even things like base URLs For an API, I'm just working on it. I want an API right now, and the API that we hit in development is staging.whatever.com.

And then what we hit in In production is a just whatever .com. There's no staging on it. So I used to check if we were in the right environment and then and then set a variable to that. And then I I just took it out and said, you know, I'm sticking the whole URL directly in an environmental variable. Mhmm. So let's talk about different types of environmental variables and and how they can be set. So at the very basic, you have plain text, environmental variables. And, Usually, when you're working locally, you'll have a file that's called the dotenv or a or a dot env.local or they have all kinds of different names, but generally, it's dotenv.

And this is just a key value file where you stick All of your environmental variables. And then when you run your code, either your framework or via a package, They'll slurp up those environmental variables, and they'll be pulled into your application so you can access them like we we've probably talked about. Oh, we should mention too that That is explicitly

something you should not do is Yes. Get that into your GitHub repo, especially if your GitHub repo is public. Now some people would say even in private repos, don't commit them. But we actually commit ours to our private repo Because our repo is going to remain private until the end of time, and it's not going to ever be public. Now there's probably a little bit of security concern there, but At the end of the day, I think we're we're okay with that being as the repo is you know, everything's locked down 2 FA and whatever. So, Yeah. Abe, for the most part, keep these things out of your repo unless you explicitly know what you're doing. Yeah. Yeah. That that's a really, really good point. And even

At both GitHub and Google, if you accidentally commit a dotenv file, and I actually did this when I This was intentional, but when I released my advanced React course, I had a dotenv dot sample just as, like, a sample of the values that we're gonna use in the course. And I commit that to GitHub because it's like a starter file. Right? Yeah. And immediately, I got an email from GitHub saying, hey. It looks like you accidentally made SMTP credentials public.

And as soon as you do that, you must go immediately reset them. If you take it down, like, 12 seconds later, it's too late. There's bots that are are waiting for these types of things To accidentally go public. So you do that. And then another one I got on Friday was when I used to teach the boot camp. We would do Google Maps examples, and Google Maps API keys used to just be, like, whatever. You get a you get one, and everybody can You can see it, and it's not a big deal. And still, it's the Google Maps API key is still a client side variable, but the because I don't know Why they emailed me about this, but I had given it to a student. And 5 years later, the student put that project up on GitHub.

I got an email from Google within 12 seconds of them pushing that commit, which blew my mind. And I was able to log in to my Google s and invalidate that key just because now those keys are like, Google Maps used to be, like, you get unlimited requests for free, and now it's, like, Six requests for a dollar or something like that. Yeah. Yeah. Yeah.

So I thought that was that was kinda cool. So there kinda is different kinds of environmental variables. There's Plain text, which is just text, but they're also are encrypted. And I I came across this in DigitalOcean's app platform, And then I noticed Vercel also has it now as well. So does render. Oh, render has it as well. It must be like a like a standard thing now across the board.

You wanna explain what they are? So it's basically

a field that you're entering into the the actual UI of your hosting platform, And that would be obfuscating and encrypting them into their database so that when you run the start scripts or whatever, it will automatically add those environment variables to your process dot node or your node process. So that way, you don't have to do anything other than implement them in their UI. You don't have to Load up an ENV file, and that's what we do for our sites even for for the the server or whatever. Our hosting platform has the encrypted values correctly, And then we only use the dotenv file locally. Yeah. That that's generally how it works with me as well. So I have a ENV file locally,

and then on The server, you have your inputs. Like, the encrypting part is pretty cool. I hadn't seen that before. And the idea behind that is that If somebody does get access to the DigitalOcean database of environmental variables Mhmm. They're encrypted, and they can only be did on your actual server, so you can do that. I switched between plain text for simple things like

staging URLs and callback URLs, things like that, and then encrypted for things like database or OAuth secrets, things like that. You know what that render has? I don't know if other platforms have it because render is the only one I've seen it. They have environment groups, so you can specify a group of environment variables Yeah. For an entire, like, service.

And let's say you have serverless functions, right, or or scheduled functions. They probably want to access things like maybe a Mongo URL with the Mongo secret. Well, you can create an environment group, and every single site that's a part of that group gets that environment variable rather than a specific one per service. And then you can override on per service basis. So you can have a group for all your things and then override them where needed. It's pretty nice. That's really, really nice. I like that a lot because I'll tell you an issue I ran into just on Friday.

I was deploying to Vercel, and Vercel allows you to have production environment variables, Staging environmental variables, and then development environment variables, which is kinda cool because you can also you can use Vercel to manage your local Variables and then pull them down. Oh, that's nice. Yeah. I I wasn't using it because I just had a dotenv file, but I thought it was kinda cool. But You can obviously use them between staging and production and in all of your serverless functions, and we'll talk about front end ones in just a second as well. And then I went to Netlify to do some stuff for my personal website, and I needed to put some variables in there. And they don't have any differentiation f. Between, like, a preview URL, like, someone submits a pull request to my blog, and it builds the website. Right? They don't have that, the differentiation between that and production.

So I had to duplicate a bunch of variables and just tag on underscore staging onto the end of them. And then in my code, I had to, like, check if we were in production or not. And usually, the way that you do that is with process s.env.node_env.

And then you're only allowed on AWS with serverless functions. You're only allowed 4,096 Characters.

And I I ran out I ran out of space. Very specific number. Yeah. Yeah. Yeah. Yeah. Yeah. And, like, It's 4 bytes. That's or 4 no. Sorry. 4,096 bytes, which is 4,096 characters if you're using Just regular regular characters. Some emojis and things like that are multiple bytes, but just regular characters are. And I ran into an issue because, like, there I just There's no way to say, okay. These are variables for staging. These are variables for production. These are variables for building my website. These are variables for the serverless functions. It's all just all in 1, and I hit that limit. And I had to just go back and rename them to be very much shorter variable names, which is a pain in the butt. But, like, that kinda is the limitation of Netlify, but, also, it's it's a hard limit imposed on serverless functions from AWS, which that's plenty if if you're able to decide which ones go where.

Mhmm. What else? If you want environmental variables In your client side, so in your React application, in your Vue application, in Next. Js, in Gatsby, you usually have To name them something special in order to surface them because you can't be going, say, process .env.databaseURL

on your React application because that would be a massive security flaw. And if those somehow got into memory or to a config and someone could find them, then you'd be you'd be in trouble. So I think the key thing to emphasize is that anything you send to the client, no matter what, can get gotten Yes. By somebody. So if you don't wanna get got, you got to not Expose any of those secrets on the client whatsoever.

Very, very important thing. So if you do want to expose them to the client because maybe they are client side API tokens, like, publishable keys like Stripe, is a good example. On Stripe, you get a secret key, Which goes on your server, and you get a public key which goes in your HTML.

And if you want to access those public ones On the front end, you have to prefix them with, and I'll give a couple of examples. Create React app is you have to prefix them with React underscore app. Gatsby, you have to prefix them with Gatsby underscore next. You have to prefix them with next underscore. In that way, you are explicitly typing it, and you say, yes. I I understand that this needs to be available

on the client side. I agree to these terms and services of what you are warning me about.

That's that's a really, really good good way to put it. What else do we have here? There is also host provided variables.

So if you wanna know, your host will often give you variables of, like, what was the git commit that triggered this build or What branch was used to trigger this build, or who was the person that made this commit? And so you can usually get all the Git stuff. You can get In Netlify and Vercel, you can get the URL that is going to be built. So if you need stuff to be specific, if you need to put, like, a canonical URL or something like that, And you you have you can access via your environmental variable, and those things are are dynamic and available to you. The one, like, weird thing I found Even on my own Gatsby website is if you want those URLs, again, on the client side, they're not available on the client side. So you have to hot potato them in your Gatsby dash node and say process .env.gatsby_commit It's equal to process dotenv.commit, and then you you explicitly prefix them with Gatsby underscore, and then there you're available to to get them.

What about like, where do you keep this is actually a question we had earlier. It's like, where do you keep your environmental variables? And we didn't have a good answer. We got a lot of tweets, Which is all the same answer. I keep my keep mine in the private repo. This is where I keep mine. Uh-oh. Yeah. Yeah. So somebody asked, like, what do you do about, like, Like, where do you keep them secretly? And some someone, like, made a a script that would, like, put them in their own folder. A lot of people just said, just put them in 1 password, and I was like, oh, yeah. Obviously. That's a great idea. Yeah.

Especially because our whole team has a a 1 Password team account, and we share passwords on it already. It's Everybody's got it set up and is logged into the team. Might as well hook them up with,

the ENV variables while you're at it. Yeah. It would. And there also is a one password CLI tool. It would be so cool if there was, like, some sort of integration.

You could probably keep them as a text note in 1 Password and then Pull that down

Mhmm.

From 1Password into a dotenv file. I see the wheels turning over there, Wes. I see these wheels turning. You you got into your your, your chin scratching mode. I was really seeing what would it take to hook It's up to a thermal printer that could print out receipts for me as well.

I think that's that's about it for All the things. The dotenv package that's available in, like, PHP, in a Ruby, and and all that. The dotenv docs used to say, don't Use multiple dotenv files. Like, only have a dotenv. Don't have, like, a dotenv dot local and a dotenv dot production.

But I, many times, have have had multiples just so that I can keep them in a file somewhere so I can reference them. Also, in In Next. Js, you have a dotenv.local.env.developmentand.env.production, and it will pull in Yeah. That's how Snowpack works. Yeah. It'll it'll pull in those different values depending on if you're building building it or if you're running in development mode. You know what? I don't

Understand the criticism against having multiple files. Like, that's like the famous GitHub issue in the dotenv npm package in GitHub. There's just, like, a lot of people having a conversation about whether or not it's appropriate to have different Dotenv files. And to me, it just makes so much more sense to have multiple files rather than to see, like, Development underscore Mongo URL. Right? You know, like Yeah. I don't know. That to me just doesn't make as much sense, but I I get it. There are conflicting or competing Ideas here. Another thing I I do wanna mention too is that you can set environment variables just in your in running node scripts, especially if you wanna test Something you can just set them right before you run the node or node mod command.

So, like, if you wanted to set an environment variable named thing, it would just be thing equals yo Node index dot j s or whatever file you're running, and that sets that variable Yeah. On process dotenv dot thing. So, like, this is Probably not something that you'll want to do long term because you'll probably have a lot of these. Not to mention, this is the type of thing that would end up in your package dot JSON file, which Again, it could be harnessing secrets, which you probably would not want to do, but it's an option in case you wanna check things quickly or or do a quick test. Often,

the only difference between, like, building and running in dev mode is if you set the node environment to production or development. Right? Mhmm. So you'll often see in NPM scripts, somebody will say, like, node underscore env equals production, and then they run their their node command. And there's even A package from Kent c Dodds called crossenv, and I use this in a couple of my courses because This works great. What you just explained works great in Unix environments, but it's awful in Windows. So cross env will Just make it work across all the environments in your npm scripts, which is super nice.

Npm install, make it work. Npm install, make it work. Yes.

Last 1 I have here is node options. Have you ever used the node underscore options environmental variable?

I've used the hyphen hyphen inspect, And I've used actually, I take this back. Yes. I have used it for more than just that. I've used it to increase the amount of RAM available in node. Is that Like, memory or some? Yeah? Yeah. It's because specifically that was I don't know if I use it anymore. I'm trying to check through my code to see if I still have any of that. There was, like, a a neat little hack that allowed you to Increase some of that memory for Meteor, and it made Meteor run a little bit smoother. Oh. And I don't see it in here. So you know? But I'm pretty sure that's how I did it. What I've used it for in the past is 2 things, is if you set the node options environmental variable before you run your node command,

It's the same thing as passing, like, dash dash whatever argument to your node command. And the the reason why that's handy is because Sometimes you're not running, like, node index dot JS. Sometimes you're running next dev or keystone init or you're you're running, like, these different Commands that use Node under the hood. If you wanna be able to pass flags to them, the the most popular one is dash dash inspect.

If you wanna use Chrome Dev Tools as your console instead of just the the terminal, and that will spin up a little external Chrome DevTools for you. And the other one is if you use the ESM package, this will hopefully not be a thing in a couple years. But the ESM package will allow you to Mix and match your common JS and your your ESM.

So if you just do node options m. Dashresm.

What that will do is it will require a package before it runs your your node script, and that will allow you to sort of insert Some magic before you actually run your code, which is super handy.

Yeah. That is as somebody who has been really heavy into the ESM world, That is essential. A bit of knowledge right there.

I think that's about it. That's surprisingly a lot to talk about environmental variables. Like, I, like, had this idea. I was like, we should do a a show on environmental variables. And I was like, ah, that's So simple. Everybody knows that. And then I went through a day of just smashing my head on the desk with

how difficult some of this stuff can be. There are some best practices and whatnot, so hopefully you enjoyed that. Yeah. I hope so as well. It is one of those things that everybody's gonna deal with, and it's not one of the more fun aspects of everything. So, Well, that sounds good. I guess we will see you on Wednesday where we Bring to you an episode on if Notion ever loads.

Notion.

Okay. Whatever. You're not getting felt like it was a bit faster today?

I thought it was too until I just tried to load this next one. So the episode on Wednesday is going to be on building your own authentication system, which is something that I have been diving into Pretty significantly given that it's going to be a 2 part level up tutorials course for us. So the authentication, a lot of stuff there. So seeing you on Wednesday again, West, when I listen to this episode. Alright. Peace. Peace.

Head on over to CSF. Use syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.