Game-Reviewer+

Game_Reviewer+ is a platform where you can write, read, and share video game reviews. It is not a site for professional critic scores, but rather a real opinion from real players. You can rate games you've played, comment on other people's reviews, react with likes and dislikes, and follow people with tastes similar to yours.

Documentation structure

Project documentation is split into two major parts:

• Markdown documentation (.md files), including this README and area/module docs.
• A PDF document in the repository root.

The .md documentation focuses on information developers need frequently while coding, or information that should always be easy to access (for example naming conventions, stack choices, etc...).

The PDF focuses more on product vision and process history, including weekly Scrum retrospectives/reviews. It documents both the direction of the project and the progress made during development.

The documentation is split into several files inside /docs:

• report.pdf - product vision and development process
• setup.md - how to install and run the project (Docker and local)
• testing.md - how to run the backend tests
• server.md - backend architecture, layers, middlewares, and environment variables
• client.md - frontend conventions, folder structure, and component rules
• observability.md - logging pipeline, metrics, Grafana dashboards, and alerts
• /diagrams/ - architecture diagrams

For API route reference, Swagger documentation is available at /api/docs.

There also may be smaller .md files inside specific parts of the codebase (for example repository info files) with focused notes for that module.

---

Stack

• Frontend: React 19 + TypeScript + Vite, Axios
• Backend: Node.js + Express 5 + TypeScript
• Database: PostgreSQL
• ORM: Prisma
• Authentication: JWT
• Documentation: OpenAPI (Swagger)
• Testing: Jest, Supertest
• DevOps: Docker, GitHub Actions
• Observability: Prometheus, Grafana, Loki, Alloy
• Security/Analysis: CodeQL, OWASP ZAP, Trivy
• External Data: IGDB API, Cloudinary

---

Code Standards

Naming Convention

• GR-<task-id>/<kebab-case-description> - branches (e.g. GR-32/auth-jwt)
• camelCase - local variables, function parameters, standalone functions, class methods, object properties, CSS module class names
• PascalCase - classes, types, interfaces, type aliases, file names, React component functions (the only functions in PascalCase)
• SCREAMING_SNAKE_CASE - module-level constants, environment variable names

Git Commit Convention

Format: KEYWORD: description; KEYWORD2: description2

Allowed keywords:

• ADD - new feature
• FIX - bug fix
• DOC - documentation
• SETUP - configs and dependencies
• CLEANUP - refactor without changing behavior
• OPTIMIZE - performance improvements
• TEST - tests
• STYLE - style

Example: ADD: Report feature, Like feature; FIX: Multiple dislikes by same user.

Git Repo Management

• main - most recent stable functional version
• dev - code from multiple branches with new features and run workflows
• tests - run workflows and tests

Docker & database

This project intentionally uses multiple environment files because each one serves a different runtime context:

• Root .env -> Docker Compose only (container and Postgres wiring)
• server/.env -> backend runtime values (JWT, IGDB credentials, etc.)
• server/.env.test -> testing context only

The separation prevents accidental cross-use of variables between local runtime, containers, and tests.

For testing, server/.env.test points to test_db (not gr_db) so integration tests never touch development data. Before each test, all tables are truncated to guarantee independent and repeatable runs.

Environment Variables

Environment variables of the server are set in /server/.env

NODE_ENV

production

• Logs are written to /observability/logs/app.log
• Disables /api/docs and /api/docs.json routes
• Non-AppError errors are sanitized to avoid exposing internal details
• Email validation is disabled to allow testing the Web App without SMTP

development

• Email validation is disabled

test

• Email validation is enabled
• Used for unit and integration tests (see docs/testing.md)
• Logs are not printed to stdout

PINO_LOG_LEVEL

Level	Description
trace	Most detailed logs
debug	Debug information for development and troubleshooting.
info	General application events (server start, requests, jobs, etc.).
warn	Non-critical issues or unexpected situations that should be reviewed.
error	Errors that affect a specific operation or request.
fatal	Critical errors that cause the application to stop or crash.

Bash Scripts

Scripts are located in the /scripts directory and must be executed from that directory You can this scripts using ./<script-name>.sh or for the Init ones bash <script-name>.sh

restart.sh

Restarts the Docker environment by rebuilding and launching all containers.

If you pass an argument, it will be passed to docker compose down, for e.g. restart.sh -v will remove persistent volumes

stop.sh

Stops and removes all running Docker containers for the project.

If you pass an argument, it will be passed to docker compose down, for e.g. stop.sh -v will remove persistent volumes

projectInit.sh

Run this script to initiate the project right after cloning. - This scripts takes a bit longer to start up the project because of the seeder Initializes the project environment in NODE_ENV=production, creates configuration files, starts Docker containers, seeds the database, and displays startup information.

runTests.sh

Sets up the testing environment, applies database migrations, and runs the automated test suite.

If you pass an argument, it will be passed to docker compose down, for e.g. runTests.sh -v will remove persistent volumes

fixIGDB.sh

Removes /server/src/IGDB/token.log - used when the IGDB token expires, or changing tokens manually in server/.env