[DING] Hello, welcome to
another Working With Data and APIs video. And in this video, I'm
continuing the Weather Here Project, and I just
wanted to one thing. One thing. A very important thing. I want to look at how to stop my
API key from just sitting there in my code. I mean, I have something
a little bit better here, which is at least the
API key is in my server code. So no one can go view source
just in the browser page and see API key is there. However, I would like
to open source this. This is a public example
I would like to post. I would like to share it. I don't want that API key just
sitting there in the code. And the way that I'm going to
address this is with something called an environment variable. An environment
variable is a variable. You know about variables. It's just like a
thing I have my code, like const API key equals. The thing is, I don't want
my variable in the code. I want it stored
in the environment. I want it to be something that's
set within the operating system or whatever framework
or system I'm using to run software itself. And I'm just pulling
it in the code. So how do I set environment
variables with node? Ultimately, there's
no one way to do this. A lot of different
platforms will have mechanisms for
storing and retrieving environment variables. And, in fact, when I look in
the next video about deploying your project to a
web server, we'll have to examine,
well, how do I have environment variables saved
on this particular web server? But a nice sort of clean way
I can do it right here locally demonstrated is by using a
node package called dotenv. So I'm going to go
over to terminal and I'm going to say
npm install dotenv. How dotenv works is summed up
perfectly in this one sentence. Dotenv is a
zero-dependency module that loads environment
variables from a dotenv file into process.env. Let me show you exactly
what this means. I'm going to go
over to the code, I'm going to just make
sure I've got it here. Yes, I've got the dotenv package
installed as a dependency. I'm going to go
to my server code. In order for dotenv
to be in action, I need one line of code,
and it's right here. I want to say require
dotenv, and then call the config function. So this is going to tell
this particular server to load anything that's
in a file called dotenv into an environment variable. So now what I need to do in
whatever text editor I'm using is I need to make a new file. And I'm going to call
this file-- guess what? Dotenv. Then this is now
a plain text file where I can put my
environment variables. Typically, you might
use all uppercase for an environment variable,
though I don't know if that's necessarily required. But I'm going to say API key-- api_key equals-- I want
to go back to my code, I'm going to grab the API key,
I'm going to go back to dotenv, and I'm going to paste it in. So now I just want to do
one thing now in the server. I want to log console.log
process dotenv. and we should see that anything
that's in the dotenv file, as long as I could require
dotenv call config, will now be inside
of process dotenv. So let's restart the server,
and we can see, oh, boy. Whoa, a lot of stuff. Look there's lots of environment
variables already there. But look at this. I've added one right
here at the bottom-- API key. There it is. Which means I can now
go here into my code, and I can change this to
be API key equals process dotenv dot API underscore key. So I can pull this API key
from the environment variable. It's no longer in
the code whatsoever. Let's remove that console log. Let's make sure the
application is still working. I'm going to run the server. I'm going to hit refresh. And looks like I'm still getting
the weather information, when I go look at the check-ins
everything is still there. I check in and I'm still getting
the weather information again. But you might be asking,
how is this any better? Sure, there's no API
key here in the code, it just says process
dotenv dot API key. But you have a file right over
here that has the API key in it right there. And so this is a convention. So it is a convention
for environment variables to be stored either
in a dotenv file or through some other
mechanism based on whatever server you're using. But not to be published
when the code is published. So this begs the question, am I
bothering to publish this code? Is this fine? How do I-- what do I
do when I deploy this? So to some extent,
this is really going to matter
when it comes time to deploy this project to
a web server somewhere. And I'm going to do
that in the next video, and we'll have to revisit
this environment variable question here. But let's just say I just want
to publish this as an Open Source project on GitHub. So why not-- [DING] Little extra feature
in this video. This feature is also
about hiding your API keys and then publishing your
project onto GitHub. And I'm going to do it in the
most lightweight, simple way possible. Now, you might be asking
yourself, what's GitHub? What's Git-- those could be
completely unfamiliar things to you. And so I'm going to refer you
in the video's description to some additional
information about that, as well as some video
tutorials that I've made of the basic interaction
to Git and GitHub. So this won't be
comprehensive at all. I'm going to kind of
assume some knowledge, but try to be as
beginner-friendly to you as possible to when walking
you through the steps. So the first thing
that I want to do is actually create another file. I'm actually going to
create two other files. I'm going to make a file,
I'm going to call it dotenv-- I'll call it like sample. So because I actually want,
when I published this, to publish a file that tells
you how to put your API key in. And so I'm just going to
say your API key here. So this dotenv sample file
is the sort of sample. It's sort of implying
rename this file to dotenv, and put your
real API key in here. And I could
probably-- in a README or somewhere I would
want to provide more context and information. But this is a nice
starting point. Then I need yet another file. I'm going to create
another file, and I'm going to
call this .gitignore. So this is really important. Git is version
control software that keeps track of all of your files
and various versions of them. What .gitignore
does, it says hey, don't keep track of this file. This is my own
personal secret stuff. I just have it
here on my machine. Don't keep track with Git,
don't upload it anywhere, don't ever use it anywhere. So in order to do that, so
I'm going to create that file. And what's the file
I want to ignore? I want to ignore dotenv. I actually also want to
ignore some other stuff like node modules. I don't want that node
modules directory. This is all of the
other people's code of all these packages. It's a huge amount of stuff. That's not something that I
want to publish and upload when I'm publishing a project. But everything else,
I could presumably maybe ignore the database. Like maybe I don't want
to keep the database, but I don't really care
about that right now. So I'm just going
to leave that be. I kind of want to ignore it. Let's ignore it. This is an interesting question. I'm not so sure whether it
makes sense to ignore or not, but I'm going to ignore it. The next step that I need to
do is go back to terminal. I'm going to go
back to terminal, I'm going to quit
the server, I am here in the directory
of this project-- The Weather Here. And I'm going to type
the commands git init. That's going to initialize this
folder as a git repository. Git init. So it initialized an
empty git repository. Then I'm going to do my first
commit of everything that's in the directory. A git commit is a
moment in time saying this is a particular
set of changes that I want a snapshot
as a moment in time with this project and
save for its history. And the truth of the matter
is, this is my first commit, so I'm just really saying
can you add all this stuff and save it. So to do that first commit I'm
going to do this in two steps. I'm first going to
say git add, which is like add all these new files. Git add, and the dot
means add everything. Now I'm ready to
type git commit. Now you might think there's
a little bit strange. Why is it two steps? Git add and then git
commit-- don't I just want to commit all this stuff? Well, this has to do with how
git works as a software system. There's a staging area
that files get added to, then those files
can be committed, and things can be moved around
in all sorts of complex ways. And this is something
that I cover in more depth in that
other GitHub video series. But for now, all
I want to tell you is that I need to
add all the files, and then I want to
commit these files. So I'm going to
say -m, and I going to put a little message here. There's more ways
you can write longer, more thoughtful
messages, but I just say this is the code from
Weather Here, as of video-- I think this is going
to be video 5-4, then I'm going to hit Enter. And then all this
stuff has been added. Now look, if you
look at this list, do you see node modules there? Do you see dotenv there? No, because those were
ignored with git ignore. The next thing that I want
to do is put this on GitHub. So GitHub is a website that
can host your git repositories. This is now a get repository
sitting on this laptop. So I'm going to navigate over
to GitHub.com/codingtrain. I'm going to come
up over here, I'm going to click this button
to create a new repository, then I want to go here,
and I want to make this-- I have a GitHub organization
which is called Coding Train, so I'm going to select that. And then I'm going to
make a project called The Weather Here. This is based on Joey Lee's
project, The Weather Here. I'm going to initialize
this with a README-- no! There's so many different
ways to do all this stuff. And I think I show you in
other videos different ways. But what I've actually-- the
steps that I'm following here, I already created
the git repository, so I don't want
to make a new one. I want to just up-- I just want to sync the two. So I'm just going to click
now, I want this to be public, I'm just going to click
Create Repository. And GitHub is so nice to me. It's just saying, this
is all I need to do here. All I need to do is
add this as a remote-- right, the coding
train Weather Here. Add as a remote, and then I
can push, which means send it. So I can just literally
copy paste to this command, go back to terminal,
type that in. Copy this command, go back
to terminal, paste that in, and I have sent all
of the code to GitHub. I hit refresh here. This is the full project here,
and if I navigate in and look at index.js, we can
see that the code-- oh, I mean, sorry, the API key
is come from the environment variable. But the environment
variable is not set. There's just an
environment sample, which is just showing
how to add your API key. And this is where, hopefully by
the time you watch this video, there won't be this
add a README button, and I will add
this README, and I will add all sorts of
information and instructions about how to work with this and
add your own API key itself. And maybe I can actually
even teleport into the future and show you a little bit
of what it'll look like. And I also want to consider
adding maybe a licensing information, a contributing
file, a code of conduct. All the kinds of things that
I might put with a new Open Source repository. So I've shown you know how
to both hide your API keys, as well as publish your
code in a git repository to the GitHub website itself. So there's one last piece
that I want to show you before I wrap up this series. How to, again, actually
run the code off of GitHub, although maybe that's
something that you'll be able to do in a future time. How can I put this code
somewhere on a server where that node server can actually
be executed, and I have either-- and I have a domain that's
hosting this website itself, that other people can access. That's what I'll show
you in the next video. See you there.
