[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.