sarowar-alam/3-tier-with-docker

1. This repository is a training-oriented wrapper around one real application: a 3-tier BMI Health Tracker. The app itself lives at the repo root, while the 01-fundamentals-containerizing and 02-compose-migration folders contain progressively more advanced Docker packaging, orchestration, and observability material for the same stack.

2. The runtime architecture is a classic three-tier flow: browser/client UI → REST API → PostgreSQL. In production, the frontend is served from an Nginx container on port 80, the backend runs as a Node.js/Express service on port 3000, and the database is PostgreSQL on port 5432.

3. The frontend is a React application built with Vite. App.jsx wires the page together, MeasurementForm.jsx handles user input, TrendChart.jsx renders historical trends, and api.js is the boundary where the UI talks to the backend. In production the frontend is compiled to static assets and served by Nginx; in development it uses Vite hot reload.

4. The backend is the application and business-logic boundary. server.js boots the service, routes.js defines the HTTP API surface, calculations.js contains BMI/BMR/daily-calorie logic, and db.js encapsulates persistence access. The backend also includes container-friendly startup behavior so it can tolerate the database not being ready immediately.

5. Persistence is centered on a measurements history model. The migrations under backend/migrations create the measurements table and later add a measurement date field, which supports the app’s historical tracking and 30-day trend views. The database setup script under database/ supports local bootstrapping outside the container path.

6. 01-fundamentals-containerizing is the “single-container-image” layer of the course. It contains production and development Dockerfiles for both backend and frontend, .dockerignore files, an Nginx config for serving the frontend, and build scripts for packaging both images. This folder is about image construction, layering, and runtime split between dev and prod.

7. 02-compose-migration is the orchestration layer. It defines a production Compose stack, a development Compose stack, and a separate monitoring stack. This is where service discovery, network wiring, volume-backed persistence, environment-variable injection, and startup dependencies/health checks become part of the architecture.

8. The observability subsystem is isolated from the application stack but connected to it. Prometheus collects metrics, Loki stores logs, Promtail ships logs from containers, and Grafana provides dashboards and datasource provisioning. The included BMI dashboard JSON indicates the monitoring layer is intended to visualize this specific app, not just generic container health.

9. CI/CD is represented by .github/workflows/docker-build-push.yml. Its role is to build and publish container images, making the Docker artifacts first-class deployable units rather than just local classroom examples. The README calls out DockerHub and AWS ECR as likely registry targets.

10. The repository also includes a small runtime/process-management boundary in backend/ecosystem.config.js, which suggests a production process manager configuration for the Node service. That sits between the application code and the container runtime, helping define how the backend is launched and supervised.

11. The setup, cleanup, and scripts folders in both class directories are operational scaffolding. They don’t change the application architecture, but they do encode how the stack is started, stopped, reset, and demonstrated across Windows PowerShell and Unix shells.

12. Net result: the core application is a stateful web system with a clear split between presentation, API/business logic, and relational persistence, while the surrounding repository layers add container image buildability, multi-container orchestration, observability, and delivery automation.