mollahhamza/yum-ai

1. Repo shape: two delivered runtimes, one main product path.

The repository is split into a React frontend and a Django backend. In the current codebase, the live architecture is a single-page app talking to a Django REST API. The README also mentions future FastAPI/AI services, but those are not present in the tree yet, so they should be treated as planned, not current, components.

2. Frontend boundary: Vite + React SPA.

FRONTEND/ is a client application built with Vite. The key runtime entry points are src/main.jsx and src/App.jsx, with feature screens under src/pages/ such as Dashboard, Inventory, Billing, Forecasting, AIInsights, Login, Register, Reports, and Settings. This implies the UI is organized as route-based pages rather than a server-rendered app.

3. Frontend API integration is centralized.

src/lib/api.js is the obvious shared API client layer. That is the main boundary where the UI likely converts user actions into HTTP calls to the backend. Styling is split between page CSS, global CSS, and Tailwind/PostCSS config, so visual concerns are kept inside the frontend package.

4. Backend boundary: Django project with REST endpoints.

BACKEND/backend_project/ contains the Django project configuration (settings.py, urls.py, asgi.py, wsgi.py). The backend exposes JSON APIs through Django URLs and views, with Django REST Framework-style serializers in each app. This is a classic API server, not a monolithic server-rendered Django site.

5. Backend is decomposed by business domain.

The backend is split into Django apps: orders, inventory, users, dashboard, and api. Each app follows the same pattern: models.py, serializers.py, views.py, urls.py, plus admin.py, tests.py, and migrations. That structure shows the system is organized by bounded domain, not by technical layer alone.

6. Orders is the core transactional subsystem.

The README and file layout indicate orders manages menu items, order creation, payment processing, and billing history. It also has a management command, seed_demo_data.py, which suggests demo/test data can be loaded into the order flow. This is the main write-heavy path in the system.

7. Inventory is a separate operational subsystem.

inventory handles stock items and stock-related operations such as listing, searching, filtering, low-stock reporting, and quantity updates. Its API surface is distinct from orders, which helps keep stock management independent from POS/payment logic. This app likely feeds both operational UI and dashboard summaries.

8. Dashboard is a read-only aggregation layer.

The dashboard app appears to expose summary statistics rather than owning primary business data. The README describes a /dashboard/stats/ endpoint with totals, popular items, and recent orders. Architecturally, this is a read model built from the transactional apps, not a separate source of truth.

9. Users is the identity/account boundary.

The users app is present with its own models, serializers, views, and migrations, which implies user/account data is isolated from the operational domains. The README says authentication is not enforced yet, so the current repo likely has the structure for user management without full auth enforcement in production form.

10. Data flow is REST over JSON, then ORM to relational storage.

The typical path is: React page → api.js → Django URL/view → serializer → model → database → JSON response. The presence of db.sqlite3 shows local development is currently backed by SQLite, while the README describes PostgreSQL/MySQL as the intended production database layer.

11. Current API boundaries are domain-prefixed.

The documented routes show separate namespaces such as /api/orders/..., /inventory/..., and /dashboard/.... That means the URL structure maps directly to business domains, which is useful for diagramming: the frontend talks to one backend, but the backend is internally segmented by domain routes.

12. Admin, tests, and migrations are supporting infrastructure.

Every app has admin.py for Django admin exposure, tests.py for app-level testing, and migrations for schema evolution. This indicates the backend is designed to be managed through Django’s standard operational tooling, not via ad hoc scripts.

13. Planned AI/ML and deployment pieces are not yet part of the runtime graph.

The README mentions Gemini/Ollama, forecasting libraries, Docker, and GitHub Actions, but no corresponding service directories exist in the tree. For an accurate architecture diagram, those should be shown as future external integrations or roadmap items, not as live components in the current repository.

14. Best diagram framing for this repo.

Draw the current system as: React SPA on the left, Django REST backend in the middle, relational database on the right. Inside the backend, split into Orders, Inventory, Dashboard, and Users domains, with shared Django project configuration above them and the Django admin/management command tooling alongside them.