How nitin020305/nutritrack works
1. Overall shape
- NutriTrack is a Flask-backed full-stack app with a browser UI on the frontend and a REST API on the backend.
- The backend owns all business logic, authentication, persistence, and third-party integrations; the frontend is a thin client that renders one HTML page and calls API endpoints.
2. Request flow
- A user interacts with frontend/templates/index.html plus static CSS/JS.
- The JS client talks to /api/... endpoints exposed by Flask blueprints.
- Responses drive dashboard views for profile, food logging, analytics, and admin operations.
3. Backend entry and configuration
- backend/run.py is the application entry point.
- backend/config.py centralizes environment-driven settings, including secrets and service credentials, with values expected from infra/.env.
- The backend uses a local SQLite database at backend/instance/nutritrack.db for persistence.
4. API boundary and route grouping
- The backend is organized around blueprints in backend/app/routes/:
- auth.py for registration, login, verification, password reset, token refresh, and account lifecycle.
- user.py for profile management and prediction.
- food.py for food search, logging, and log deletion.
- analytics.py for daily, weekly, and monthly summaries.
- admin.py for bootstrap, user management, stats, and log access.
- This routing layer is the main architectural boundary between HTTP and domain logic.
5. Authentication and access control
- Authentication is JWT-based.
- Email verification is a separate gate for actions that require a verified account, especially food logging and analytics.
- Admin routes are role-protected; the README shows a bootstrap path for establishing the first admin user.
- Shared auth checks and token helpers live in backend/app/utils/auth_helpers.py.
6. Core domain model
- The primary persisted entities are in backend/app/models/:
- user.py for account/profile/admin state.
- food_log.py for logged meals/items and dates.
- nutrient.py for nutrient-related caching or lookup data.
- The database schema in database/schema.sql serves as the structural reference, while database/seed.py creates initial users for setup.
7. Food and nutrition pipeline
- Food lookup and logging are not just CRUD; they pass through service logic in backend/app/services/food_parser.py and usda_api.py.
- The app integrates with an external USDA nutrition API for nutrient search and enrichment.
- backend/app/utils/unit_converter.py suggests inputs are normalized before storage or calculation, so food entries likely move through parsing, unit conversion, then persistence.
8. Analytics and chart generation
- Analytics endpoints aggregate logged food data into daily, weekly, and monthly summaries.
- backend/app/utils/chart_generator.py indicates the backend produces chart-ready output or server-generated visualizations for the dashboard.
- This is a distinct reporting layer built on top of stored food logs rather than a separate analytics service.
9. Prediction and personalized user features
- backend/app/services/prediction.py provides a weight prediction or similar user-specific inference function exposed through the user API.
- This sits beside profile management, implying the app combines static account data with computed health insights.
10. Notifications and email workflows
- backend/app/services/mail_service.py handles transactional email flows such as verification, resend-verification, password reset, and likely account-related notifications.
- The README specifies Gmail app-password setup, so email delivery is an external SMTP dependency rather than an in-app queue.
11. Operational/admin layer
- Admin endpoints expose platform-level visibility: user lists, user status updates, stats, and access to all food logs.
- This makes admin a separate operational subsystem with elevated privileges over the same underlying user and log tables.
12. Frontend deployment model
- The frontend/ directory contains a single-page-style browser app implemented with vanilla HTML/CSS/JS, not a separate frontend framework.
- It likely consumes the Flask API directly and handles session/auth token usage on the client side.
13. Infrastructure and packaging
- infra/docker-compose.yml and infra/Dockerfile indicate the project can be containerized for local or deployment environments.
- backend/requirements.txt and the README’s matplotlib note suggest the backend has both standard web dependencies and chart/visualization support.
- The architecture is therefore a monolith with clear internal layers, externalized config, and optional containerized runtime.
14. Key architectural boundaries to draw
- Client/browser boundary: static frontend versus API backend.
- HTTP/API boundary: blueprints separating auth, user, food, analytics, admin.
- Service boundary: business logic and external integrations isolated from routes.
- Persistence boundary: SQLAlchemy models and SQLite database.
- External dependency boundary: USDA API, SMTP email, and environment-managed secrets.
Main entry points: run.py App Entry · main.js Client JS · food.py Food API · admin.py Admin API
Components 23
Frontend
Single-page browser client and assets
- Browser UI · Single-page HTML client with CSS/JS
frontend/templates/index.html - Client JS · Calls API endpoints and updates dashboard views
frontend/static/js/main.js - Styles · Presentation layer for the browser app
frontend/static/css/main.css
API Layer
Flask entrypoint and route blueprints
- App Entry · Application launch point
backend/run.py - Config · Central environment-driven settings and secrets
backend/config.py - Auth API · Registration, login, verification, reset, refresh
backend/app/routes/auth.py - User API · Profile management and prediction endpoints
backend/app/routes/user.py - Food API · Search, logging, and log deletion
backend/app/routes/food.py - Analytics API · Daily, weekly, and monthly summaries
backend/app/routes/analytics.py - Admin API · Bootstrap, user management, stats, and log access
backend/app/routes/admin.py
Backend Core
Shared utilities and business services
- Auth Helpers · Shared token and access-control checks
backend/app/utils/auth_helpers.py - Food Parser · Parses and normalizes food input
backend/app/services/food_parser.py - USDA API · Nutrition search and enrichment source
backend/app/services/usda_api.py - Mail Service · Verification and password-reset email delivery
backend/app/services/mail_service.py - Prediction · User-specific weight or health prediction
backend/app/services/prediction.py - Chart Generator · Builds chart-ready analytics output
backend/app/utils/chart_generator.py - Unit Converter · Normalizes food quantities before storage or calculation
backend/app/utils/unit_converter.py
Data
Models and database artifacts
- User · Account, profile, verification, and admin state
backend/app/models/user.py - Food Log · Logged meals, items, and dates
backend/app/models/food_log.py - Nutrient · Nutrient cache or reference data
backend/app/models/nutrient.py - Schema/Seed · Database structure and initial user seeding
database/schema.sql - SQLite DB · Persistent storage for NutriTrack
backend/instance/nutritrack.db
Ops
Containerization and packaging
- Docker Stack · Compose and image packaging for runtime
infra/docker-compose.yml
Connections 33
- Browser UI → Client JS: loads · The browser page is driven by client JavaScript
- Browser UI → Styles: styles · The page uses static CSS for presentation
- Client JS → Auth API: calls · Client requests auth endpoints
- Client JS → User API: calls · Client requests profile and prediction endpoints
- Client JS → Food API: calls · Client submits food searches and logs
- Client JS → Analytics API: calls · Client fetches summary data
- Client JS → Admin API: calls · Client accesses admin operations when permitted
- App Entry → Config: reads · Startup uses environment-driven configuration
- App Entry → Auth API: registers · Flask application wires in blueprints
- App Entry → User API: registers · Flask application wires in blueprints
- App Entry → Food API: registers · Flask application wires in blueprints
- App Entry → Analytics API: registers · Flask application wires in blueprints
- App Entry → Admin API: registers · Flask application wires in blueprints
- Auth API → Auth Helpers: uses · Routes rely on shared JWT and auth checks
- Auth API → Mail Service: sends · Verification and reset emails are triggered here
- User API → Prediction: uses · Profile API exposes prediction features
- Food API → Food Parser: uses · Food API parses and normalizes entries
- Food API → Unit Converter: normalizes · Quantities are converted before persistence
- Food Parser → USDA API: queries · Food enrichment uses external USDA data
- Analytics API → Chart Generator: builds · Analytics endpoints produce chart-ready summaries
- Admin API → Auth Helpers: protects · Admin routes are role-gated
- Admin API → User: manages · Admin operations act on users
- Admin API → Food Log: reads · Admin operations inspect food logs
- User API → User: reads/writes · Profile data is stored in the user model
- Food API → Food Log: writes · Food logging persists meal records
- Food API → Nutrient: looks up · Food flows consult nutrient reference data
- Analytics API → Food Log: aggregates · Summaries are computed from food logs
- User → SQLite DB: persists · User data is stored in SQLite
- Food Log → SQLite DB: persists · Food logs are stored in SQLite
- Nutrient → SQLite DB: persists · Nutrient data is stored in SQLite
- Schema/Seed → SQLite DB: initializes · Schema and seed data define the database state
- Docker Stack → App Entry: runs · Container image starts the backend app
- Docker Stack → Browser UI: serves · Containerized deployment includes the browser assets