Managing Environment Variables

[00:00:00]
>> The last thing that I wanna show is I wanna show how to manage environment variables in Gatsby because it's, very straightforward but there's a little bit of a mental model around. Really all the static site generators, anything that builds client side code usually has a convention for the difference between an environment variable that should be available to the client.

[00:00:23]
And one that should only be available in the build process and in server less functions, and Gatsby is no exception. So what we can do for this is I wanna create a couple environment variables and I'll start by just having a let's create a page. And our page is going to be called nvs.js.

[00:00:45]
And so I want to import everything is react from react and then we're going to export default function and various page. And what I wanna do on this page is just return details about what the environment variables are. So this is huge caveat here. What we're doing here is for demo purposes.

[00:01:14]
This is actually a terrible idea. Don't share your environment variables publicly on your website. Now, an important thing to note is that anything that is available to the client side is embedded in public code. So if you put an API key that shouldn't be public Into your Gatsby public environment variables.

[00:01:36]
Someone can go inspect your bundle and find that key. So it's really important that you only expose things to Gatsby on the client side that can be publicly shared. Because anything that you do will be put into the code as a publicly available environment variable. So Let's just give ourselves a header we'll say environment variables.

[00:02:01]
And then down here I'm going to just we're gonna dump two. So the first one is gonna be called Gatsby public value. And we wanna show process dot m dot Gatsby public value. And then the other one that we wanna show is going to be called secret value.

[00:02:24]
And these are two separate kinds of environment variables in Gatsby. The first kind is prefixed with Gatsby underscore. This is a signal to Gatsby B that this variable is allowed to be on the client site. And this is a really important thing to note because it's effectively an opt in.

[00:02:44]
You're saying by prefixing this environment variable with Gatsby underscore. I am acknowledging that I am about to make this value public. It's going to go into my source, bundle secret value down here, though. Gatsby is not gonna pick that up. So I'm actually expecting that once we set these, this one shouldn't show me anything.

[00:03:05]
But right now they're not set at all. So let's set some environment variable. So I'm gonna M set Gatsby public. Value and I wanna set that to this is okay to share. Then I'm gonna run it again and set secret value, this is a secret right, so these are just placeholders.

[00:03:33]
These aren't real environment variables. But this is how you would also store your say, API token. If you were gonna read from GitHub or you wanted to send email with a service like mail gun or send grid or something, you would have an API key that identifies your account.

[00:03:51]
And those need to stay secret. So those would not be prefixed with Gatsby. And another thing that I'm doing here is I'm using the the Netlify COI to set these because one of the things that is a pain to me at least is trying to manage different dot n files and then like so I'm working on a site and I've got my dot env.

[00:04:11]
And then I deploy and then the site fails because the environment variables aren't set. And then I like share it with my co worker, and they can't get it running because they don't have the environment variables. So by using the COI, what we're actually doing is we're setting it at the project level.

[00:04:27]
So when I ran this COI command what actually ended up happening is in my project when I go to the build and deploy and then environment, these get set from the COI. And then what's even cooler is what I'm about to show you here is when I run netlify dev Look at that, from the site.

[00:04:49]
From app.netlify.com these got pulled down for local depth. So it'll also pick up dot n file so that you don't have to like write a dot n or anything like that. But it is so nice to just set my environment variables once and then not have to think about if I share this site if I publish it environment variables are there.

[00:05:07]
If I send it to a co worker and they're on my netlify account, environment variables are already there. So all these things that somebody would need are, they're all like managed in a very nice way. So let's go check out this inverse page and let's see if we got the expected outcome.

[00:05:23]
And we did look so Gatsby public value. Okay, that's what I expected. We can see this, and it would show up in the source code as well, if we were to use this somewhere in like a react component. Secret value, though, is empty. It's not shared. And the reason that this works is that what Gatsby is doing at build time is it's actually replacing these values wholesale.

[00:05:49]
So it is going in and looking for process dot m dot Gatsby public value. And it will then remove this entirely. So the source code, what's actually being published here is not this, it's the value. It's like that, right? So that's what's being done and what's being shared.

[00:06:12]
So this is a very cool process where, you basically said if it's prefixed with Gatsby got to grab it. Another caveat to this, is that that means that you can't do things like this, like Gatsby, public value, equals process.env, unless they've changed this recently, because this won't get picked up.

[00:06:40]
Maybe they rewrote that it used to be that it was it was like wholesale match like process dot and had to be present. But that's the thing to keep in mind because that does happen in other frameworks like. I think next has that issue where you need to use the whole life process.mstring.

[00:06:58]
But it looks like Gatsby fixed it so good for them, one less thing to worry about. So, the other thing though is that once you've set an environment variable like this, you do wanna be able to access it in your Serverless functions. Because that's what serverless functions are there for is to do work with sensitive details because they're secure.

[00:07:19]
Nobody can get the code inside of a serverless function unless it's like, unless they have access to logging something out of it. So if you write the code and you don't log any of your secrets, you can use them in here. And no one will be able to get at him.

[00:07:35]
So it's a good way to do like secure form submissions or sending mail or things like that. So if I create a API call called n vair and this one is gonna export default function handler, and we'll get a, we don't want to use the rest, so we'll use the res.

[00:07:54]
And then in here, I'm going to res.Json. And let's just get the same thing from here. So we don't have to retype all of this out. Okay, so that is going to give us our values back. And again, big disclaimer, this is a terrible idea. Don't return your environment variables from a call.

[00:08:32]
Looks like I need to restart to get that function to pick up. It's not plural. That's what's wrong. There we go. So we can see that in the serverless function, the environment variable is there. So this is how we can work with these private values, like if I need to make a privileged call, I would do it in a serverless function.

[00:08:53]
And then I can return the results of that without exposing my keys. So this is another way that that server less functions kind of level you up as a developer as, they give you access to do this sort of thing that otherwise, you'd have to go stand up a server.

[00:09:07]
And you'd have to deal with all these other things that there's nothing inherently wrong with them, but it's just one more chore that you have to do before you can solve the problem at hand. And what I like about serverless functions is we were just here we can just do the thing, right?

[00:09:21]
So this then get this set up if we wanna get add everything. And let's get commit, we'll say add and their demo. It's, Just gonna add up big old like this is not a great idea. Don't do this. So let's push and we'll see when we go back to our deployments here that it's already building.

[00:09:50]
And it's gonna pull in our environment variables. And we will get the same output on the client side and this should happen. Hopefully we'll see how it goes. It should happen in about a minute because the cache is warm. While we're waiting for this to build, does anybody have any questions because we are starting to come to the end here.

[00:10:11]
We're gonna do some further resources and q&a and then we're gonna call this thing a wrap. So if you've got questions for today, now's the time
>> The serverless functions piece kind of lifted their mental blocks around the power of serverless functions and like cookies and mental block around working through that.

[00:10:33]
>> No joke when I, started working with serverless functions, I think before I picked them up, I had in my head, that there was just a ceiling. To what I was capable of unless I wanted to go and be a full stack Dev. And I've been a full stack dev the beginning of my career was actually more on the PHP MySQL side.

[00:10:54]
And as I moved more into the front end, I just found that I preferred that. I preferred working on the front end It made me I don't know, it was just more fun for me, I guess. And so I would get to this certain point in any project where I would just start looking at the tasks and I'd be like, this isn't worth it.

[00:11:16]
I don't wanna go that far back into the stack. So whatever idea I had, I'd start talking myself out of it, and start convincing myself that what I wanted to do was was too ambitious, too expensive, too much time and just not worthy, you will have a different idea right?

[00:11:31]
When I adopted server less functions, it was like this fog cleared and suddenly all of my ideas were possible. And so we've been able to do Just so much goofy fun stuff we good example of, like serverless functions, unblocking things is we wanted to build this thing for explorers where you could like take courses and learn stuff.

[00:11:55]
In order to do this, I needed like I wanted OAuth, I wanted you to have an account. So we needed to set up this OAuth workflow. Well, turns out that was server less functions. I did this in three functions. And now I've got actual login and I can go and have a dashboard, and all this apparently I achieved something in my [LAUGH] I did something I guess.

[00:12:16]
But I can see like now completed tasks in jamstack explorers and I've like earned a certificate and downloading the certificate is also a serverless function. We take your name and then we generate a I think it's an SVG file, turn that into a PDF and then we return that to you.

[00:12:33]
And we with the missions out here we're doing checks to see like, when you watch one of these, we're sending off serverless function calls to track, how many seconds of it have you watched. All of these things are things that in my mind, were like, that's too much work.

[00:12:48]
I am not gonna build a server that can manage that. But with serverless functions, each one of these things is one tiny function. I don't think any function on this project is more than a dozen or maybe two dozen lines of code. And that gives us the ability to just build whatever we want.

[00:13:05]
I'm completely unblocked. And so if you wanna see some more like ambitious, like real world projects, this is a good one the netlify explorers repo has a bunch of functions in it of, here's how we handle our auth. And here's how we do certificates and here's how we're checking whether or not you had an achievement, sending off reward stuff, all sorts of funding things that we can do in here.

[00:13:31]
And all of that is possible with serverless functions in a way that it wouldn't have been or would have been significantly more complex for us to build had we tried to stand up like an Explorer's micro service. That ran all of those as one kind of back end.

[00:13:47]
So yeah, It really does. I don't know I just I feel like it gave me extra power like, instead of feeling like being a front end dev has a ceiling. Now I feel like being a front end dev is a superpower because the hard part in a lot of cases is making it look and feel fun to use.

[00:14:09]
And that's the part that I enjoy that's the part that I'm good at is building fun websites. If I can jump over to my silly website and make some goofy stuff that like let's make the website make a boot noise whenever you click a button or have like, sound Effects things like that.

[00:14:31]
But then when I wanna make it useful, I wanna pull stuff from different services or I wanna hook in my blogs. Or something like all of those things that we can do, I just have a serverless function to enable that. So I can go pretty deep in the stack without having to go tap on the shoulder of somebody who's a back end Dev.

[00:14:50]
So I feel like my world expanded to the border of limitless, there's still stuff like I still every once in a while, build a real server. I'm trying to do real time or I'm trying to set up a graph qL subscription or something like that. But in almost all of the normal day to day cases that I hit, I found that a serverless function gets me there and takes me a fraction of the time.

[00:15:14]
So I really am all in on serverless. I think it's such a cool way to work. And in such a power up for front end developers, web developers to go out and just build whatever you can imagine. So our site's built, I wanna go and just poke at it real quick and make sure that inverse thing did what we expected.

[00:15:36]
So here's our environment variables. Again, the secret value is not there, public value is there in the website. And then we also have in our API no trailing slash that the API has access to our secret variables. So this is the the general experience that you're looking at inside of Gatsby is you can share these environment variables.

[00:16:02]
You can do all that and because we manage them with netlify, they were all kind of often out of the way after we set them once. Instead of having to get that dot n file from my local machine into settings on another machine.