Enable the use of .env for setting runtime variables and non-static setting of CORS allow_origins

[jhodapp]

Description

This PR enables the use of .env for setting runtime variables alongside CLI params. Also accept a list of CORS allowed origin URLs instead of hardcoding them.

GitHub Issue: None

Changes

• Enable the use of a .env file at runtime for setting all of the command line flags
• Allow the setting of a list of servers to allow for CORS Allow Origins purposes

Testing Strategy

1. Test using the following .env file when running the backend as bare metal or when building the Docker containers

# PostgreSQL environment variables for local development
POSTGRES_USER=refactor  # Default PostgreSQL user for local development
POSTGRES_PASSWORD=password  # Default PostgreSQL password for local development
POSTGRES_DB=refactor  # Default PostgreSQL database for local development
POSTGRES_HOST=postgres  # The local Docker Compose PostgreSQL container hostname
POSTGRES_PORT=5432  # PostgreSQL default port for local development
POSTGRES_SCHEMA=refactor_platform  # PostgreSQL schema for the application
# Database connection URL for the Rust application
# Rust application environment variables
ALLOWED_ORIGINS="http://localhost:3000,http://localhost:3001,http://*.rove-barbel.ts.net:3000,https://jims-macbook-air.rove-barbel.ts.net,https://jims-macbook-air.rove-barbel.ts.net:3000,http://jims-macbook-air.rove-barbel.ts.net:3000,http://100.66.34.44:3000,http://192.168.1.65:3000,http://192.168.1.111:3000"
DATABASE_URI=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
INTERFACE="0.0.0.0"
LOG_LEVEL_FILTER="DEBUG"
PORT=4000

NEXTJS_FRONTEND_PORT=3000

CONTAINER_NAME="refactor-platform"

# App user configuration
USERNAME=appuser  # Username for the non-root user in the container
USER_UID=1000  # User ID for the appuser
USER_GID=1000  # Group ID for the appuser

Concerns

None

[calebbourg]

This looks great! Thank you for adding this.
Just a question and a request:

Q: Does this mean we will not have to specify a .env file when running the app with docker-compose? If so will it correctly distinguish between something like .env and .env.local?

R: Could you provide a new example .env file in the docs that uses the new variable names?

[calebbourg]

I wonder if it would make sense to change this to debug! so we don't log the URI in production? Thinking more of down the line if we are using like an AWS database. Not really sure if the URI itself would contain any sensitive information but just a thought.

[jhodapp]

Great question, I actually had it as debug originally but I messed up the order in my mind. I'm going to switch this to TRACE so that it only shows up when we really want it to. And at some point we may even decide that this is not even necessary.

[jhodapp]

This looks great! Thank you for adding this. Just a question and a request:

Q: Does this mean we will not have to specify a .env file when running the app with docker-compose? If so will it correctly distinguish between something like .env and .env.local?

It appears that by default, dotenvy only loads a .env, but it does have a function if we want to provide a way to load from something custom-named like .env-local.

R: Could you provide a new example .env file in the docs that uses the new variable names?

Happy to.