Using environment variables is a standard practice for modern software development. A question you might have is, why do we use environment variables? It is common to have multiple deployed instances of our application, also called environments. For example, a dev environment for continuously deploying our code staging, which is a replica of production for testing before production deployment, and of course production, which is the instance of our application used by our commercial clients. Storing information for accessing external resources like databases directly in our code ties all these environments

to a specific instance of the external resource. As you can imagine, this will be a problem for a number of reasons. For example, the production database will collect development junk, and this also means that anyone with access to the source code will be able to access the production database without any peer review. Moving this information into environment variables allows us to use the same code deployed to different environments with their own environment variables, which allows us to scale our external resources to multiple instances. Note that this is not the only benefit of using environment variables,

but even this by itself is enough to motivate the usage. The good news is that next JS comes with built-in support for loading environment variables, and we don't need to install any additional packages. We can provide environment variables in a dot n file, so we create this within the root of our project, and here we provide key value pairs where the key will be the environment variable name followed by the equal sign and the value. We can use these environment variables within our code. For example, within a server page, we are going to render out the D-B-U-R-L in a simple diviv. To read the value of an environment variable,

we use the global process N, which is provided by node js. When we run our next J server, it'll automatically pick up that an environment configuration file do NV has been provided. When we run our application in the browser, you can see that process dot n do DB URL has been replaced by the value that we provided in our environment file with next js. There are actually two categories of environment variables. The first category are the ones intended for use on the server. These are the things that we need to keep secure. An example of a server only environment variable is database access, URL.

The second category are the ones that we want to be available for access from the front end code of our application, which also makes them accessible to users because the front end code is shipped to the user's browser. An example of a public environment variable is the tracking ID used by browser analytics services. Note that the public environment variables are also available for access on the server. However, the server only environment variables cannot be directly accessed from client side code, which is why the categories are called server only versus public. By default, all environment variables are considered server only.

In order to make a public environment variable, you need to explicitly prefix its name with next public. In addition to our server only environment variable, we create a new public environment variable called tracking id, and to ensure that it's public, we prefix it with the next public. As we know, a server component Only runs in a server context, which means that we can access D-B-U-R-L as well as next public tracking. Id note that normally you wouldn't log server only environment variables in a client response, but this is only for demonstration. Effectively, it is the same as creating an HTP endpoint and sending a server only value to the client.

Next, we jump into a client context by creating a client component as specified by the Hughes client directive. Within our client component, we use the same code that we wrote in our server component. We log out the D-B-U-R-L as well as the public tracking id. Since this is a client component, next J will only provide us with a public tracking ID and the D-B-U-R-L over here will actually be undefined. So let's verify that by using the browser. When we visit our server component, you can see that both the environment variables were provided. However, when we visit our client component, DB URL is undefined and only the public environment variables are accessible.