30 lines
2.1 KiB
Markdown
30 lines
2.1 KiB
Markdown
# 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.
|
|
|
|
## 2. Environment-based Configuration
|
|
|
|
- **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).
|
|
|
|
## 3. Frontend to Backend Communication
|
|
|
|
- **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.
|
|
|
|
## 4. Docker Configuration
|
|
|
|
- **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).
|