vikrammadhyasta/agritech

1. What this repository is

- This is a frontend-only React application for the AgriTech platform, built with Vite + TypeScript and styled with Tailwind/shadcn/ui.

- The repo also includes the delivery pipeline and Kubernetes deployment manifests, so the architecture spans UI, build, containerization, and GitOps deployment.

2. Primary runtime boundary

- The app boots from index.html → src/main.tsx → src/App.tsx.

- App.tsx is the top-level composition point for routing/layout; the rest of the app is organized as page-level views and reusable UI components.

3. Route/page structure

- src/pages contains the major route targets:

- Public pages: Index, About, Products, Contact

- Auth flow: src/pages/auth/AuthPage.tsx

- Error handling: NotFound

- Role-specific dashboards: CustomerDashboard, DistributorDashboard, FarmerDashboard, RetailerDashboard

- This suggests a client-side routed SPA with public marketing pages plus authenticated role-based sections.

4. Layout and reusable presentation layer

- src/components/layout contains global frame elements like Navbar and Footer.

- src/components/home groups the landing-page sections (HeroSection, FeaturedProducts, StatsSection, AboutSection, ContactSection), which are composed into the home page.

- src/components/dashboard/DashboardLayout.tsx is the shared shell for dashboard pages, separating dashboard navigation/chrome from dashboard content.

5. Design system and UI primitives

- src/components/ui is a large shadcn-style component library: dialogs, forms, tables, tabs, tooltips, sidebars, toasts, etc.

- These are not business-specific; they provide the application’s consistent interaction primitives across public pages, auth, and dashboards.

6. State, responsiveness, and shared utilities

- src/hooks/use-mobile.tsx and src/hooks/use-toast.ts provide cross-cutting client behavior for responsive UI and notifications.

- src/lib/utils.ts likely centralizes common class/utility helpers used throughout the component tree.

- src/components/NavLink.tsx is a small navigation abstraction, probably used to keep navbar/sidebar links consistent.

7. Backend/data integration boundary

- The only explicit backend integration in the repo is Supabase under src/integrations/supabase.

- client.ts is the browser-side Supabase client; types.ts provides generated type safety for database records.

- supabase/migrations/...sql shows the database schema is managed separately from the frontend, so the frontend talks to a managed backend/data layer rather than a custom API server in this repo.

8. Data flow at application level

- User visits the static frontend, navigates through public content, and authenticates via the auth page.

- Role-specific dashboards then consume data from Supabase-backed services/database.

- The README describes domain actions like farmers listing produce, distributors verifying quality, retailers selling products, and customers placing orders; these are presentation/data flows rather than local business logic services inside this repo.

9. Styling and asset pipeline

- tailwind.config.ts, postcss.config.js, src/index.css, and src/App.css define the styling pipeline.

- components.json indicates component generation/configuration typical of shadcn/ui.

- The app is built as a static frontend bundle, with public/robots.txt and public holding static assets.

10. Containerization and local/runtime packaging

- Dockerfile packages the built frontend into a container image.

- There is no app server code in the tree, so the container likely serves static files generated by the Vite build.

- This is the artifact that gets pushed to the registry and deployed to Kubernetes.

11. CI/CD control plane

- Jenkinsfile defines the automated pipeline: source change → build → image creation → push to registry.

- The README describes AWS ECR as the private registry, making Jenkins the build-and-publish boundary between source control and deployment.

12. Deployment target and GitOps flow

- k8s/deployment.yaml, service.yaml, and application.yaml define the Kubernetes-side deployment.

- The README says ArgoCD watches GitHub and syncs Kubernetes manifests, so deployment is GitOps-driven rather than manually applied.

- Kubernetes is the runtime scheduler/exposure layer; the Service exposes the app, and the Deployment pulls the image from ECR.

13. Registry and secret handling

- The deployment uses an image pull secret for private ECR access, which is a critical infrastructure boundary.

- This means cluster access to images is intentionally separated from build access, and the manifest set must include imagePullSecrets support.

14. Architecture summary for a diagram

- Draw the app as a static React SPA with:

- user-facing pages and dashboards in the frontend

- Supabase as the managed data/auth backend

- Jenkins building Docker images

- AWS ECR storing images

- Kubernetes running the containerized frontend

- ArgoCD continuously syncing manifests from GitHub

- The key boundaries are UI vs. data/backend, build vs. runtime, and source control vs. cluster deployment.