coderayushraj-png/campus-connect

1. Top-level shape

- This repo is a client-heavy full-stack campus platform: a React/Vite frontend, a Supabase backend for auth/data/storage/realtime, and a small server/edge-function layer for automation and AI-related workflows.

- The app is organized into three major experiences: auth, student portal, and admin portal.

2. Frontend shell

- src/main.jsx, src/App.jsx, src/index.css, and vite.config.ts form the browser app entry and build pipeline.

- The UI appears to use a route-grouped app structure under src/app/, with separate layouts for student and admin, and dedicated login/signup screens under (auth).

- vercel.json indicates production deployment is intended to be served as a frontend app on Vercel.

3. Route and role boundaries

- Authentication pages live in src/app/(auth)/login and signup.

- Student-facing pages are grouped under src/app/(student) and include dashboard, notes, events, placement, forum, notices, clubs, lost-found, deadlines, profile, and settings.

- Admin-only pages live under src/app/admin and cover dashboard, analytics, notices, placements, events, clubs, and users.

- src/app/(student)/layout.jsx and src/app/admin/layout.jsx are the main boundary points for shared navigation and role-specific shell UI.

4. Cross-cutting UI components

- src/components/AIBuddy.jsx is a persistent AI assistant component, likely embedded across the app shell rather than tied to a single page.

- src/components/NotificationBell.jsx is the global notification entry point for unread counts and alerts.

- These are the main shared interaction surfaces connecting multiple subsystems.

5. Supabase is the core backend

- src/lib/supabase.js is the central client used by the frontend to talk to Supabase.

- The backend responsibilities are spread across:

- Supabase Auth for login/signup and role-based access,

- PostgreSQL for campus entities like notices, events, notes, users, placements, and forum content,

- Supabase Storage for uploaded files such as PDFs and images,

- Supabase Realtime for live updates without refresh.

- supabase_seed.sql suggests the repository includes seeded demo or initial data.

6. Student-data flows

- Student pages are read-heavy dashboards over shared campus data: notices, deadlines, placements, events, club activity, forum posts, notes, and lost/found listings.

- Typical flow is: frontend page → Supabase query → live updates via Realtime → UI refresh.

- The student dashboard likely aggregates multiple collections into a single overview, while the specialized pages drill into one domain each.

7. Admin-data flows

- The admin portal is the write/control plane for the system.

- Admin pages manage the same core entities that students consume: notices, placements, events, clubs, and users.

- This creates a clear architectural split: students mostly consume data, while admins publish and govern it.

8. AI and RAG layer

- The repo includes a separate server/ directory with server/rag.ts plus a top-level server.ts, which suggests a server-side AI or retrieval service distinct from the browser app.

- The README describes AI-driven features such as the buddy assistant and notice Q&A, so the AI layer likely combines:

- context retrieval from campus data,

- a Groq-backed LLM call,

- and response streaming back to the UI.

- This is a separate intelligence boundary from the CRUD app logic.

9. Automation and scheduled jobs

- supabase/functions/check-deadlines/index.ts and send-deadline-email/index.ts are Supabase Edge Functions.

- Their role is operational automation: scanning upcoming deadlines and sending reminder emails.

- This is the repo’s background-processing path, likely triggered by Supabase Cron rather than by user interaction.

10. Email and external integrations

- The README indicates transactional email delivery through Resend.

- That means deadline notifications are not just in-app alerts; they also leave the system through an email delivery service.

- Groq is the other notable external dependency, used for low-latency AI responses.

11. Security and access control

- The architecture relies on role-based access at both the UI and data layers.

- Admin/student separation is enforced by route layout structure in the frontend and, per the README, by Supabase Row Level Security in the database.

- This means the access boundary is not only visual; it is enforced where the data is stored.

12. Deployment/runtime split

- The frontend is built with Vite + React and deployed on Vercel.

- Backend logic is split between Supabase-managed services and serverless edge functions.

- The presence of server.ts/server/rag.ts adds a second server-side runtime path, likely for AI orchestration or API mediation.

13. How to draw the architecture

- A good diagram would show:

- Browser UI at the top,

- branching into Auth, Student Portal, and Admin Portal,

- all talking to a shared Supabase backend,

- with a side lane for AI/RAG service,

- and a background lane for scheduled deadline/email automation.

- The main system boundary is the Supabase-backed campus data platform; everything else is either presentation, AI enhancement, or automation.