refactor: move environment variables to docker-compose and remove example.env

[NotYuSheng]

Summary

This PR refactors environment variable management by moving variables from .env files into docker-compose.yml with sensible defaults, improving container orchestration and simplifying deployment.

---

Changes Made

• Move environment variables from .env files into docker-compose.yml with defaults
• Refactor USE_AUTH_TOKEN to HF_TOKEN for clarity (Hugging Face token)
• Simplify LLM_API_URL to base URL only, move /v1/chat/completions to backend code
• Remove env_file references from docker-compose services
• Remove obsolete example.env file since vars are now in docker-compose.yml
• Update backend to construct full API endpoint from base URL

---

Context / Rationale

This refactor improves the deployment experience by:

1. Eliminating the need for separate .env files
2. Providing sensible defaults directly in docker-compose.yml
3. Making environment configuration more transparent and easier to manage
4. Clarifying variable names (USE_AUTH_TOKEN → HF_TOKEN)

---

Related Docs or References

• Simplifies the setup process for new developers
• Follows docker-compose best practices for environment management

---

General Checklist

• I have tested these changes locally
• I have updated relevant documentation or added comments where needed
• I have linked relevant issues and tagged reviewers
• I have followed coding conventions and naming standards

[gemini-code-assist]

Summary of Changes

Hello @NotYuSheng, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

I've refactored the project's environment variable management to centralize configuration within docker-compose.yml, eliminating the need for separate .env files and providing sensible defaults. This change streamlines the deployment process and clarifies variable naming. Concurrently, I've significantly upgraded the frontend's deployment strategy by implementing a multi-stage Docker build with Nginx, enhancing performance and maintainability. These changes are complemented by a series of UI/UX improvements and a more robust audio processing workflow, including new recording controls and job status polling, to provide a smoother and more informative user experience.

Highlights

• Centralized Environment Variable Management: Environment variables such as USE_AUTH_TOKEN, LLM_API_URL, and LLM_MODEL_NAME have been moved from separate .env files directly into docker-compose.yml. This centralizes configuration with sensible defaults, simplifying the setup process for new developers and improving overall environment management.
• Backend API Refinements and Variable Renaming: The backend's handling of the LLM_API_URL has been refined; it now expects a base URL, with the full /v1/chat/completions path being constructed dynamically within the backend/main.py code. Additionally, the USE_AUTH_TOKEN variable was renamed to HF_TOKEN for clearer identification of its purpose. The /logs endpoint was also removed.
• Frontend Deployment Overhaul with Nginx: The frontend deployment strategy has been significantly overhauled to utilize a multi-stage Docker build with Nginx. This change improves performance by serving static files efficiently and aligns with best practices for production deployments. A new nginx.conf file was introduced to manage routing, API proxying, and other web server configurations.
• Enhanced User Interface and Experience: The user interface has received substantial updates, including new CSS variables, linear gradients, and shadows for a more modern aesthetic. Key UI elements such as a dark mode toggle, audio preview capabilities for both recorded and uploaded files, and refined recording controls (pause, resume, discard) have been added or improved, enhancing the overall user experience.
• Robust Audio Processing Workflow with Job Polling: The audio processing workflow has been made more robust. The frontend now supports pausing and resuming live recordings, and users can discard recorded audio or uploaded files before processing. A new job polling mechanism has been implemented to provide real-time feedback on the status of transcription jobs, improving the reliability and transparency of the audio processing pipeline.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a significant refactor that improves the project's deployment and environment variable management by moving configurations to docker-compose.yml and introducing a production-ready multi-stage Docker build for the frontend using nginx. The changes are generally positive, enhancing clarity and following best practices. However, I've identified a few critical issues, primarily in the backend, where the removal of a logging function breaks other parts of the application, and a hardcoded CUDA device setting could cause crashes without a GPU. There are also opportunities to improve maintainability in the nginx configuration and the React components by reducing code duplication and addressing the use of !important in the CSS.

[gemini-code-assist]

The deploy configuration for GPU resources has been commented out. However, backend/main.py still has DEVICE = "cuda:0" hardcoded on line 49. If the service is deployed on a machine without a GPU or without the docker daemon configured for GPU access, the backend will crash when trying to move the model to the CUDA device. The backend code should be made more robust to handle the absence of a GPU, for example by checking torch.cuda.is_available() and falling back to CPU if necessary, or by making the device configurable via an environment variable.

[gemini-code-assist]

os.getenv("LLM_API_URL") can return None. str(None) evaluates to the string 'None', which will result in an invalid URL like 'None/v1/chat/completions'. This will cause a request error. It's better to check if the environment variable is set and handle the error gracefully.

Suggested change

	base_url = str(os.getenv("LLM_API_URL"))
	url = f"{base_url.rstrip('/')}/v1/chat/completions"
	base_url = os.getenv("LLM_API_URL")
	if not base_url or base_url == "CHANGEME":
	raise ValueError("LLM_API_URL environment variable not set or is default.")
	url = f"{base_url.rstrip('/')}/v1/chat/completions"

[gemini-code-assist]

The configuration for /jobs/ and /jobs is duplicated. You can combine these into a single location block to improve maintainability and reduce redundancy.

    # Proxy API requests to backend
    location /jobs/ {
        proxy_pass http://backend:8000/jobs/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Handle preflight requests for CORS
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE, PATCH';
            add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }

    # Also handle exact /jobs endpoint (without trailing slash)
    location = /jobs {
        proxy_pass http://backend:8000/jobs;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Handle preflight requests for CORS
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE, PATCH';
            add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }

[gemini-code-assist]

Using a wildcard * for Access-Control-Allow-Origin is overly permissive and can pose a security risk. It's recommended to restrict this to the specific domain of your frontend application in a production environment. You should consider using a variable like $http_origin and validating it against a whitelist of allowed origins.

[gemini-code-assist]

The use of !important is generally discouraged as it can lead to CSS that is difficult to maintain and debug. It seems to be used here to override the base button styles. Consider refactoring the CSS to achieve the desired styling through higher specificity or by restructuring the selectors to avoid the need for !important.

[gemini-code-assist]

The state variables isPlayingRecording and isPlayingUpload are set but never read. This suggests they might be unnecessary. If their values are not used to conditionally render anything or in any logic, you can remove them and their corresponding useState calls to clean up the code.

[gemini-code-assist]

The functions uploadFile and processAudio share a lot of duplicate code for handling form data, making the API request, and polling for job status. This could be refactored into a single, more generic function to improve maintainability and reduce redundancy.