Transcript
  • Meteor
  • Tutorial

Organizing Environment Variables and Settings

In this video, I'm going to show you one way you can use environment variables and settings with your Meteor applications in development and in production.

In my configuration directory, I'll create a settings file. I'll just call it settings.json. And then we'll open up that file.

The JSON file can contain public settings, which are available on the client and on the server. And all of the other settings are only available on the server.

In your public settings, you might have something like a mix panel public key. And in your private settings, you might have something like your AWS key. These are just contrived examples, obviously. Now to start up my Meteor application with these settings, I can say, meteor dash S settings, and then pass that path to the settings file.

Then over in the browser, if I take meteor.settings, I can see the public settings are sent down to the browser. We don't see the private settings here, but those would also be available on the server. So Meteor settings is a nice place to store key value pairs that we need for configuring our application.

Another way we can create global variables is by using environment variables. You've probably already used a few of them, just to configure a Meteor application regularly. For example, we can specify a Mongo URL. In this case, we'll say that we want to use a MongoDB that's located at local host, port 27017, and we'll create a test DB-- if one doesn't exist already. And then we can start up our Meteor application like normal, and we'll pass the settings file.

But typing in these environment variables onto the command line every time is pretty cumbersome, and error-prone. And so I prefer to have an environment file that I can source when I start up the meteor application. Let me show you.

Let's create another file inside of the configuration directory. We'll call it env.sh. So this'll be a shell script file. The first line will say that this is a bash script or a shell script. And what we'll do is just export our environment variables here.

So I can say export Mongo URL equals, and then we can give our Mongo URL right here. And I could export any other environment variables that I want here. Like, for example, my AWS key, or my root URL.

Now to start up my Meteor application, I can either create a simple shell script to help me do that, or just write from within the terminal-- I can source my new config env.sh file. And so that will load up all of the environment variables that we just created. So, for example, if I wanted to echo the Mongo URL, the value of Mongo URL, I can see that it's been loaded into the current environment. So now I can start up Meteor, and it will have access to those environment variables.

But in production, how do we get access to that settings file? If we're just starting up a main.js file with node js, there's no settings flag that we can use. Well, it turns out that Meteor also accepts an environment variable called Meteor Settings, which can be set to a JSON string. So what we need to do is to set this environment variable, and the value of it will be that JSON file.

The way that we can read in the JSON file directly into this value is we can type the dollar sign, and then use the cat command, and we'll give a path to the JSON file. And then hit Enter. And now if we echo the value of Meteor settings, it should be equal to our JSON file.

Now, to make this a little bit easier, what we can do is open up our environment.sh file and just put this in there. So in the last line or so you could say, export Meteor settings is equal to cat config settings.json. Or wherever the path to your settings JSON file is.

Now what we can do is source our env.sh file, and start up Meteor as usual. And the great thing about this approach is it works equally well in development and in production. And so I just bundled up this sample application. And if I wanted to load up the proper environment variables, I can source the environment.sh file, and then start up the regular main.js file with node.

I've logged into the main Evented Mind application server, so you can take a look at my project directory there. I'm not going to go into all of the detail here in this video, but you can see that there's a script called Start. And this is a shell script that I wrote that helps me start and stop the Meteor application.

And so if we take a look at that file, you can see one of the first things it does is it sources the environment sh file and the configuration directory for production or development or staging-- or whatever environment that I happen to be in. And then using Forever, I start up the current bundles main.js file using node js. And our environment and settings and everything are already loaded into the environment by sourcing this file.

This video is part of a new track that's coming out soon, called Meteor Deployment and Scalability. And in that track, we'll look at how to take a Meteor application from nothing to deploying it to Amazon's cloud, using Amazon's OpsWorks platform. So we'll look at how to deploy to multiple application servers with a load balancer, and configure, and keep everything up to date pretty easily.

So check out that track, it's coming out soon.