How to separate your test, development and production databases using NODE_ENV.

Kristian-Roopnarine — Fri, 27 Nov 2020 18:22:42 +0000

Why should you separate your test, development and production databases?

As your applications become more complex you're going to incorporate different methods of testing to help ensure that your application works as intended. Of course this doesn't make your application 100% bullet proof, which is why proper testing is important, but why is it important to separate our testing environment from development and production? When running test suites, there is usually some degree of changes made to the database in the form of updating entries, adding, deleting, forcing errors etc. We want to make sure that when we run our tests, they don't rely on previous data to ensure that one test doesn't influence another. An easy way to do this is to implement some clean up method before and after a test is run, which usually means clearing a database and filling it with the same dummy data.
Running a test suite on a production database would be irresponsible because a test might have unwanted side effects and alter the state of our database, or worse it would reveal information about our tests and source code. The data inside of the production database is always changing as well, which means that a test suite might work one day, but fail another day because the same data was altered causing our tests to fail.

How to separate application environments using NODE_ENV

We can store environment variables in the node process (highly encourage you to read up on this if you're not familiar). Then we can access any of these variables in any part of our program. These variables are also secure so it is common to store API keys, credentials and other secrets inside of the node process. When running our node applications we can set the NODE_ENV and conditionally change the applications settings based on this NODE_ENV. It is a common practice to store these variables as key=value pairs inside of a .env file shown below.

The environment is set to development by default and one implementation of this is found below by changing our the URI to our database.

This does not have to be used with mongoose, it was just an example. But depending on the environment our application will use a different database. This can be used to change the settings of other features as well, maybe you want to enter a testing environment for stripe, or sandbox environment to test an SDK.

How to set NODE_ENV

Now that we know how to conditionally render settings using NODE_ENV, how do we set NODE_ENV when running our application? A common approach is to set them in package.json scripts:

{
  ...
  "scripts": {
    "start": "NODE_ENV=production node ./app"
  }
  ...
}

This way you can start an app in either a test, development or production environment.

Add docker to your NodeJS workflow in just 4 simple steps

Kristian-Roopnarine — Wed, 18 Nov 2020 09:13:17 +0000

What is docker and why should you use it?

Docker is a platform as a service which allows you to isolate an entire operating system via Linux containers. The files we create below are instructions for how Docker should build the Linux container. Dockerizing (is that a word?) your application should be the first step in your workflow as it provides a good base for your development and production environments. Onboarding new members to the project is easy too, just provide them the respective Dockerfile and they’re good to go. Docker can become extremely complicated and you can add a lot of configuration to your application with Docker alone.

You will definitely benefit from spending time researching complex features of Docker!

Add docker to your NodeJS app in 4 steps

I don’t explain what the following code does, but docker has great documentation on it, https://docs.docker.com/engine/reference/builder/ .
All of the following config files will be at the root of your project. These files will work for probably 90% of your NodeJS applications, barring specific configuration.
If this is an application that will be shipped to production, create a separate Dockerfile.prod that contains configuration for your production application. These config settings can be googled because there are many people who have used Docker in production. This helps separate dev vs prod configuration with ease.

Create a Dockerfile.dev with the following code:

Create a docker-compose.yml with the following code:

Create a .dockerignore and add node_modules to it. Any files/folders in the .dockerignore will not be copied over to the Docker container. Since node_modules is usually a large directory, adding this to a .dockerignore this will speed up your build times. Add other files/directories you do not want to be copied into your docker container here!

Execute the following commands in the root directory of your project depending on what you need:

docker-compose up -d --build : Builds the container using Dockerfile.dev and starts your docker container in detached mode
docker-compose up -d Starts your docker container in detached mode
docker-compose down ALWAYS run this command when stopping your container
docker ps Lists your current active containers

After the initial build is successful execute docker ps and ensure that your container is running. If so, head on over to localhost:5000 where your application is hosted locally. You can change this port through the port setting in the docker-compose.yml .