DEV Community: John Behan

Using Environment Variables in your app

John Behan — Thu, 11 Mar 2021 12:43:31 +0000

Keeping secrets

Some values in your application are unique to where your app is being run. For example you may be testing your app against a local server when you are developing it on your computer. But when you publish your app you will want it to use a publicly available server on the Internet.

Another issue you face is maintaining values in your app that you don't want to share publicly. Things like an API Key or a database password are examples of these. You can have them in your code when working on your computer. But when you push your code to a repository, or share it with a colleague, you don't want to send these secret values.

Managing these values can be painful. It is very easy to forget to change them before publishing or pushing your code.

If you forget to change a value that points to a local server your app will break. Worse - it may break for everyone but you as you are still running the local service your app needs 🤦🏼‍♀️
Forget to remove secrets and you risk publishing sensitive information. At best this will mean a cleanup job for your Git repository and a quick change of those secrets. At worst.... well that's a subject for another day.

There is a simple solution for these probelms.

Environment Variables

Let's break this down a little. The environment can be:

The computer you are using when writing your application.
For a backend service it could be the server that you deploy your application to.
A frontend application may need to go through a build step. The environment in this case is the system where you perform the build step.

You are already familiar with variables. They are a way to refer to a value stored in memory. Environment Variables are the same.

Example

The example application is a Node service which is connected to a database. It is deployed to Heroku. Heroku is one of the easiest ways to deploy a node application. Setting Environment Variables there is straightforward. But you could use any platform - Environment Variables will be available there too.

This app has both problems I outlined at the start:

You may want to use a local database during development. But your app uses a different database for production. So you need to change the database connection string when deploying.
The connection string is a secret that you do not want to share. You do not want this information leaking to the Internet. Doing so would compromise the integrity of your application and the security of your data.

You can solve these problems by using Environment Variables. The best way to do this on your local machine is to use the dotenv package.

Install dotenv: npm i dotenv
At the top of the main file of your application (index.js for example) add: require('dotenv').config()
Create a .env file in the root directory of your application
Add the variables the app needs into this new file. For example: DATABASE_CONNECTION_STRING=mongodb://localhost:27017
Add .env to your app's .gitignore file.

Now replace any instance of the database connection string with process.env.DATABASE_CONNECTION_STRING

Adding .env to your app's .gitignore file solves the second problem - exposing sensitive information. Now when you push your code to the repository the database connection string is not included.

You still need to address how to use Environment Variables when your app is deployed. The production database will have a different URL. For example its connection string could be mongodb://xyz456-shard-00-00.ab123.mongodb.net:27017

In Heroku you can add this information with Heroku's Config Vars. Remember to use the same variable name - DATABASE_CONNECTION_STRING

That's it! When your app is deployed to Heroku it will connect to the production database.

Key Takeaway

I hope you can see how effective Environment Variables will be for you in your code. They are quite easy to start using. But as with anything - the more you practise using them, the easier they become to use.

Look through your code. Check for any places you are hardcoding values that are dependent on the environment. Some places to look are:

database connection - username, password, url
api keys and ids
path such as your app's url

You can also use Environment Variables in your frontend code. The underlying principle is the same.

Proof of concept for How They Voted

John Behan — Fri, 21 Aug 2020 16:40:52 +0000

A project I am working on - How They Voted

TL;DR - Check out How They Voted and the How They Voted organisation on Github

This is an app to easily see how TDs (elected representatives in Ireland) have voted on issues in the Dáil (Irish parliament).

It is very early stages now but the goal is to create something to allow users to easily answer the question:

How did {my-local-td} vote on that issue/bill/motion?

This is what the mobile version of the app looks like:

And this is the desktop version:

Built with Svelte and Sapper

I've been using Svelte and Sapper a lot lately - this site was recently migrated from Gatsby to these in a few days.

The How They Voted app is built to run as a statically generated site using Sapper's export script.

It's hosted on Github Pages and is deployed on a merge to Master using Github Actions.

I'm really happy with it. It is very early days now but the main page of the app has a Lighthouse score of 95 - Performance, 100 - Accessibility, 100 - Best Practices, 100 - SEO.

The app is a PWA by default. I haven't done anything with this though yet, it's just built using the default Sapper settings.

Using public APIs

All the data used in the app is pulled from the oireachtas.ie servers unless stated as coming from elsewhere.

The APIs provided by the team there are very good and any questions I have had have been answered in good time and always with extra info.

I wasn't able to retrieve some data through the API so I created some scraping tools with Node and Puppeteer.

Idea and goals

The main goal for this project is to give a non-partisan view of the public dealings of our government. I believe that the more engaged and informed we are of what is happening in government, the more we can influence what happens there and can hold our elected officials to account.

I have a few ideas about where to go next with the app:

Better design
TD stats - how they tend to vote, what issues they engage with, etc...
Services to automate collection of data (currently happens manually)
Peer reviewed contributions for naming, tagging, summarising votes and debates

Contributing

There is a lot of work needed to make this app achieve all its goals. These contributions will be for code, content, ideas, governance and probably a hundred other things I haven't thought of yet.

It's my first time working on a project like this and I've regularly questioned my motives and the whole concept but it has also been fun to work on. I'm looking forward to seeing where this all goes :D

Using attributes in Rust to suppress warnings

John Behan — Sun, 22 Mar 2020 10:25:27 +0000

Warnings and errors are good. We want to be told when we're doing something wrong or something with the potential to cause problems in the future. But sometimes it's ok to turn off those warnings.

Turning off a warning in Rust at the code level

fn main() {
  let mut my_variable = 'foo';
  my_variable = 'bar';
}

If we try to compile this block of code we will see this warning -

warning: variable my_variable is assigned to, but never used

By adding #[allow(unused_variables)] above the variable declaration we can suppress this warning

But there is another warning -

warning: value assigned to my_variable is never read

We can suppress this warning by adding #[allow(unused_assignments)] above the line that reassigns my_variable. Or...

If we add #[allow(unused_variables, unused_assignments)] above the function. Our code now looks like this and gives no warnings when compiled.

#[allow(unused_variables, unused_assignments)]
fn main() {
  let mut my_variable = "foo";
  my_variable = "bar";
}

Suppressing warnings when developing can be useful as it reduces the amount of noise we need to filter out when we're trying something out or debugging. But it is important to turn these warnings back on and to address any underlying issues once our code is ready.

Managing Rust binary files and Git when using rustc

John Behan — Mon, 16 Mar 2020 16:54:08 +0000

What is rustc?

rustc is the compiler for Rust. When we use cargo to compile our source files it is actually calling rustc to do all the hard work.

Don't believe me? :D Use this command to see the full output from a call to cargo.

cargo build --verbose

rustc outputs the compiled binary file to the same directory as it is called in.

rustc hello.rs will create the binary file hello in the same directory as our source file hello.rs.

Where does Git come in to this?

All good. But if we are using Git we don't want to commit these binary files to our repository. "Let's just use a .gitignore file" I hear you cry. Perfect but we can only git ignore files and directories by name not by type or anything else.

A little trick we can use is to create a folder called bin and git ignore that. Then use the following when compiling with rustc -

rustc --out-dir bin hello

Now our source files and binary files are kept apart and our binaries never make it into the Git repository.

Getting started with Rust on Mac

John Behan — Sat, 14 Mar 2020 19:40:03 +0000

The Easy Way^TM to Install Rust (on a Mac)

The easiest way to install Rust on a Mac is to head on over to https://www.rust-lang.org/tools/install and use the shell command there -

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

But...

Sometimes we get the following error -

Unknown SSL protocol error in connection to static.rust-lang.org

Sometimes. I got this on my work machine but not my personal one.

You can read a bit about this issue here - https://www.wormly.com/answers/sid/142/topicid/19

There is a fairly straightforward solution

The Fairly Easy Way^TM to Install Rust (on a Mac)

(See Update below before trying this)

We want to use rustup so let's get that first.

brew install rustup

Next let's setup cargo and rustc,

rustup-init

Finally we can check our installation with - rustc --version

UPDATE

jeikabu on Dev.to has given this tip to try.

The old way of installing rustup - curl sh.rustup.rs -sSf | sh

I haven't tested this but it is worth trying before falling back on brew.