Research: Deployment Configuration

Date: 2025-10-15

This document outlines the technical decisions made to enable deploying the application to a custom host.

1. Backend CORS Configuration

Decision: Use the cors npm package in the Express.js backend to manage Cross-Origin Resource Sharing.
Rationale: It is the industry-standard, robust, and highly configurable middleware for enabling CORS in Node.js. It provides a simple way to whitelist origins, which directly addresses FR1.
Alternatives Considered: Manually setting CORS headers. This is error-prone and less maintainable than using a dedicated, well-tested library.

Decision: All deployment-specific values (CORS origins, API URLs) will be managed through environment variables.
Rationale: This decouples configuration from the codebase, adhering to Twelve-Factor App principles. It allows developers to easily switch between localhost and production environments without changing code.
Alternatives Considered: Hardcoding values (violates principles), using configuration files (less flexible than environment variables in containerized environments).

Decision: The frontend will use a REACT_APP_API_URL environment variable to determine the backend's address.
Rationale: This is the standard convention for Create React App applications. It ensures the frontend can be pointed to any backend during development or after deployment.
Alternatives Considered: None, as this is the idiomatic approach for this frontend stack.

Decision: The docker-compose.yaml file will be updated to pass host-level environment variables into the respective frontend and backend service containers.
Rationale: This is the standard and most effective method for injecting runtime configuration into Docker Compose services, allowing for flexible deployment.
Alternatives Considered: Building separate images for each environment (inefficient), managing configuration inside the container (violates immutability principles).