Accessing Environment Variables in an Easier Way

Christopher Daniel — Tue, 15 Jun 2021 01:45:26 +0000

In server-side development, it's extremely common to access variables from the execution environment.

In this post, I hope to convince you to consolidate access of these variables into one single-file (or a more structured way of accessing these values) to make it easier to refactor, maintain, and update as your project grows.

// Logging to console the stage we're on
console.log(`This is the ${process.env.NODE_ENV}`);

Why is it useful to access variables from the environment?

I won't dive too much into the why of this, but you typically access sensitive values via this way, such as

API keys and secrets
Application identifiers
Stage of the environment (looking at you NODE_ENV)
JSON Web Token key
Database access credentials
other top-secret values of this nature

These are values that you do not want committed to a version control system like GitHub and so you keep them out of there for security purposes.

You might also keep these out of there because these vary from stage to stage, and thus makes no sense to keep in GitHub.

So, getting them during runtime of the program it is! 😃

What's the issue with process.env?

In your own projects, you might be accessing environment variables through process.env.MY_VARIABLE. This is great! It's fine, and it works.

But is it optimal?

Imagine you have two files that access the same environment variable, some sort of API key

// Usage 1
axios({
  url: `${process.env.CMS_URL}/random-endpoint-1`/v1/random-endpoint-1`
  header: `Bearer ${process.env.MY_API_KEY}`
});

// ...

// Usage 2
axios({
  url: `${process.env.CMS_URL}/random-endpoint-1`/v1/random-endpoint-2`
  header: `Bearer ${process.env.MY_API_KEY}`
});

Both of these files are accessing the same API key from the environment directly. Now imagine your projects expands in scale and you have many more instances where this API key needs to be accessed.

See the problem that might occur? You now would process.env.MY_API_KEY littered throughout your project.

What if you need to change the environment variable from process.env.MY_API_KEY to process.env.TWITTER_API_KEY?

Yes, you can easily rename all instances (using a powerful editor like VS Code). But this is going to cause a pretty large commit created for this simple change.

What if you have a plethora environment variables, and you want to group them? Like API credentials, database credentials, etc.?

There's no way to do this with the normal process.env.XXX_YYY usage. Everything is at the same level and there's no grouping them.

What if you want to add context to each environment variable, so engineers can understand what purpose they serve?

You can do this in your .env.template file as single-line comments, but this won't show up in the IDE as a hint or documentation for your team members.

How should we be accessing the environment variables?

I won't say you 100% definitively, absolutely, should follow my advice. But I think it can help prevent the above shortcomings (and also add to your current environment variable usage).

Add a config.js or config.ts file!

What do I mean?

I mean consolidate access of environment variables from using process.env.XXX_YYY everywhere, to just accessing it once! Through a single file(s)!

It can look something like

export const Config = {
    cmsUrl: process.env.CMS_URL,

    dbHost: process.env.DB_HOST,
    dbUser: process.env.DB_USER,
    dbPassword: process.env.DB_PASSWORD,
    dbName: process.env.DB_NAME,

    jwtSecret: process.env.ZEROCHASS_SECRET,

    awsRegion: process.env.AWS_REGION,
    awsBucket: process.env.AWS_BUCKET,

    twitterApiKey: process.env.TWITTER_API_KEY,
}

Now, whenever I want to access any of these environment variables, I can do so by importing this file.

No more having to write process.env.MY_VARIABLE over and over!

My above example with axios becomes this

import { Config } from './config';

// Usage 1
axios({
  url: `${Config.cmsUrl}/random-endpoint-1`
  header: `Bearer ${Config.twitterApiKey}`
});

// ...

// Usage 2
axios({
  url: `${Config.cmsUrl}/random-endpoint-2`
  header: `Bearer ${Config.twitterApiKey}`
});

If I ever need to change the environment variable that the Twitter API key was stored in, I don't have to change a zillion files, I just change it here in config.ts!

If I need to add documentation and group items, I can easily add it here.

export const Config = {

    general: {

      /** The URL for our Craft environment */
      cmsUrl: process.env.NEXT_PUBLIC_CRAFT_CMS_URL,

      jwtSecret: process.env.ZEROCHASS_SECRET,

      /** The stage we're on, should be QA/Dev/Prod */
      nodeEnv: process.env.NODE_ENV,
    },

    database: {
      host: process.env.DB_HOST,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      name: process.env.DB_NAME,
    },

    aws: {
      region: process.env.AWS_REGION,
      bucket: process.env.AWS_BUCKET,
    },

    twitter: {

      /** API v1 URL for Twitter */
      apiUrl: process.env.TWITTER_API_URL,

      /** API key for our Twitter app */
      apiKey: process.env.TWITTER_API_KEY,
    },
}

And anyone who imports this file will get all that context, including the code hints on hover!

Hopefully this short post has given you some insight on how you might rethink your environment variable usage. You can even throw in some value-validation here, but I won't cover that here.

Let me know your thoughts!

Add some color to your profile picture! 🎨

Christopher Daniel — Sat, 05 Jun 2021 16:48:14 +0000

Hey all! The Twitter community is a great place to find and interact with folks from all over on shared passions and interests.

Most recently, I've been way more active on Twitter and becoming a more active part of the developer community.

It's been an awesome time sharing knowledge and building in public along with learning from what others have to say.

One thing that can help with others recognizing you and your content is making your profile stand out a bit.

There's a million people online and standing out can help with people remembering who you are and what type of content you tend to put out.

With all that said, adding a nice and eye-catching color to your profile picture can really add some pizazz to your profile picture! Regardless of where you're using it (except LinkedIn, where your mileage may very 🙂).

Profile Picture Maker

This is the main step of creating your very own profile picture with a colored background. Profile Picture Maker

Most of the time, this app will work without a hit, and you'll get some awesome different styles for your profile picture.

In the below example, I've uploaded a picture of Justin Timberlake.

You can even select from a multitude of colors for your background.

After uploading your profile picture, it just takes a few second to generate your different pictures.

See the neat results below

After you've picked your favorite, you're good to go with uploading it to Twitter, Facebook, or wherever you want.

If Profile Picture Maker isn't working for you

Sometimes, Profile Picture Maker might not colorize your entire background, or it might colorize something that isn't your background.

This was the case for me, where my white hat was being seen as part of the background and so was being colorized as part of the background-coloring process.

In comes Photo Scissors to the rescue! You can use this app to manually crop out the background from your profile picture.

In doing so, only the transparent background will be left, which will be easy for Profile Picture Maker to identify and colorize properly.

And that's it!

Hopefully you've found some value from this post and can make your profile picture a nice and unique color for others to see and recognize.

Until next time!