Environment Variables in SSR

[00:00 - 00:10] The last demo was with a single page application or a spa using React. But what do you do when your app framework uses a completely custom approach to environment variables?

[00:11 - 00:25] Today I'll show you how to tackle that using a library called Gatsby as an example. For proper search engine optimization or SEO, you'll often see user technique that uses server-side rendering or SSR.

[00:26 - 00:39] Gatsby is one of the most common libraries for SSR for React behind Next. But I don't want you to focus on the technology setup since the technology that we use is inevitably going to be outdated.

[00:40 - 01:03] I want you to be left with the skills necessary to determine a process for setting up your environment by yourself. So when deciding between demoing Next or Gatsby, although Next is the more popular option, Gatsby was unique because it does not use React script, so we cannot rely on the typical methods of environment variable loading.

[01:04 - 01:23] And for Next, we could just use the methods learned in the previous video because it's built more or less the same way as React. When you're figuring out how to implement .env with a new library, first search for environment variables in the documentation.

[01:24 - 01:32] You can look on GitHub, but let's look on Google. Gatsby environment variables.

[01:33 - 01:41] And there is something in the documentation about that. So let's see how they're doing it.

[01:42 - 01:59] It seems that they have a config and the config looks a lot like a Webpack config. Next, figure out if you want to have multiple flows or if you're okay with just one environment type.

[02:00 - 02:17] If you don't need flow at this point, you can safely just follow whatever the documentation says or treat it as any other Webpack config setup. But in this case, we're going to be experimenting locally, so it will be handy to use flows.

[02:18 - 02:32] You probably won't need multiple flows, but for the sake of demoing the process , I'll show you how to do it. Since there isn't a lot of information, we have to do some investigation to see if the .env library is built into the tool chain.

[02:33 - 02:42] So let's go take a look at the package.json. There's a sense via Monoribo.

[02:43 - 02:51] We want to find Gatsby. And let's see the package.json.

[02:52 - 03:00] And it seems that it is using .env. So .env is already built into the tool chain.

[03:01 - 03:16] So since it is present, that means that the documentation is probably a little bit inaccurate. We'll need to actually find out if the value of .env is being overwritten.

[03:17 - 03:31] Is that something that's very common to happen when they have that in the dependencies for tools? So let's find out by searching for node_env.

[03:32 - 03:38] And usually, we'll find places in the code where that is being overwritten. This thing is not working.

[03:39 - 03:47] I'm trying to basically show the Gatsby active.env, but it's actually not coming up. So I'm going to show a different way to do this.

[03:48 - 04:18] So the best thing to do is actually to search into issues and look for anybody trying to set the value of node_env to development. And what you find is that there actually is a variable Gatsby active.env that is being advised instead of node_env because this is being overwritten.

[04:19 - 04:43] And you can tell that by looking that up, Gatsby active.env. And right there in the webpack config, the config_env that they're using is actually Gatsby active.env before the node.

[04:44 - 04:59] So there will often be cases where this value is overwritten. And so for that reason, it's just safer to set the value of Gatsby active.env directly instead of node_env.

[05:00 - 05:09] We can now build the starter application. So I'm just going to go with the starter default and I've built it in my other screen.

[05:10 - 05:32] So since .env is built into the tool chain, we don't really have to do much configuration, contrary to the documentation. All we have to do is make sure that our scripts are set so that way we are reading from the correct .env file and that we have our .env files set up accordingly.

[05:33 - 05:58] So since we know that .env is already part of the tool chain, there's no point trying to use .env flow library or any other custom .env because we're just going to be clashing with the main .env library. So the better option is to just try and make it work with what you have.

[05:59 - 06:24] And so in this case, what I recommend is that just so you want to have a staging, well, we'll first create the .env file. So .env and then we'll have a staging.

[06:25 - 06:53] And then just for show, we'll do a .env development. So just a reminder, because we're not using flow, we can't use any merging techniques like local or even merging a base .env default set with one of the development or staging sets.

[06:54 - 07:09] So we actually have to put all the config values in whichever environment that you're going to be using. So now that we have our three .env files, let's give a reason to use it.

[07:10 - 07:42] So in our index.js, let's just add some things so that way when the page is welcomed, we'll say welcome to instead of Gatsby, we'll say process .env .gatsby_name. So we have to put Gatsby_ just because it will only render .env variables that have Gatsby_ as the prefix.

[07:43 - 07:56] And now what we'll do is let's build it. This should not work, but let's just build it.

[07:57 - 08:17] Now that it has built, let's serve it and we'll see what that looks like. As we can see, the welcome to shows a blank because Gatsby_name is not there, it's not set.

[08:18 - 08:34] And so now what we need to do is let's make sure that that's set in the respective N files. And then we'll play around with the various environment float names and we'll see what that looks like.

[08:35 - 09:06] So let's set a value in each Gatsby_name equals output default just so that way we know what that is because I'm going to demonstrate that flow is not working properly. And we'll say I'm going to spell it wrong just so that way we know that it's not printing out the name of the type of flow.

[09:07 - 09:32] And now that we've done that, let's serve that again. And actually when we serve that, it still doesn't show anything. But the reason why is actually because, well, when you run npm run serve, the value of the environment is actually production and we didn't create a production.

[09:33 - 09:46] And so let's go do that. Now, okay, I created a production file, gave it a value, let's restart the serve.

[09:47 - 09:53] And I'll show you what that looks like. Still nothing.

[09:54 - 10:21] Well, I'll tell you why because you have to rebuild between each time you change the value of your environment. This is because it's looking for change. When you run the serve command, it does look for changes in the files, but it does not look for changes in the dot end files. It only looks for the changes in your JavaScript related files.

[10:22 - 10:36] So let's go back, you run the build and then reserve. Okay, that's built.

[10:37 - 10:45] Let's see what that looks like. All right, so now we have that value of there. We have the production value showing up.

[10:46 - 11:00] We also know since no value showed up when there was no value for production that the default value is not working. So you must have a value. You cannot rely on a default.

[11:01 - 11:15] And now let's see how we can change which environment we're going to be reading from. First thing is we know that this default is not working, so I'm just going to throw that out so that way I don't confuse myself.

[11:16 - 11:39] And the other thing is that in our package JSON, we want to make it easy so that way we want to build or serve or whatever that we are using commands that make it easy to choose that really quickly. We also know that so let's I'm going to use build dev.

[11:40 - 12:00] And we also know that to set the value to override and node and value we have to use Gatsby active end. So we'll do that Gatsby active end equals development.

[12:01 - 12:14] And that should do it. Actually, let's not do build dev because develop already builds and also serves your develop build.

[12:15 - 12:25] So let's just do something fun. So staging. And I'll show you what that looks like to staging.

[12:26 - 12:37] And we'll also create a serve command for that. So serve staging.

[12:38 - 12:53] And then we'll have to put that again Gatsby active end equals staging Gatsby serve. Okay, so let's see what that looks like. So right now we have our develop.

[12:54 - 13:19] So running and we'll show you what that looks like as expected. We have the dev showing and as a and let's let's go see what happens when we put it to staging mode. So one thing occurred to me that well, remember, we already set the environment value up in build. So why do we even have to have a second serve?

[13:20 - 13:33] Well, yeah, we don't need to. So let's take that out. We just need the one and we just have to set our active end in the build section. I'll prove I'll show you in just a sec.

[13:34 - 13:55] And there you have it. You got your staging value showing, which means that we 're successfully able to choose which environment we wanted to show. So how difficult was that really? Well, the difficult part really was understanding how to do it and not really in terms of what needed to get done.

[13:56 - 14:14] All we had to do is have a separate build section and understand what this development and figuring out our process for which environment type we wanted to use. And then it really just showed up on its own using our process end. And there you have it. See you in the next one.