sanyamjain-16/educationchatbot

1. This repository is a full-stack chatbot platform for a coaching centre use case: a public marketing site, an authenticated admin dashboard, an embeddable chat widget, and server-side APIs for chat, knowledge ingestion, and billing.

2. The app is organized around file-based routing in src/routes, with a public area (index, login, signup, chat.$token, widget.js) and a protected dashboard area under src/routes/_authenticated. The protected routes cover chatbot management, analytics, billing, leads, onboarding, settings, and admin views.

3. The frontend is a React app styled with a component library pattern (src/components/ui) and assembled into higher-level sections like hero, pricing, testimonials, FAQ, stats, footer, and trust blocks. These are mostly presentation layers for the landing site and dashboard screens.

4. Interactive product features are split into reusable UI subsystems: chatbot builder/demo/widget, custom cursor, 3D background/hero scenes, neural network visuals, device showcase, energy timeline, and embed-snippet generation. These are mostly client-side experience layers rather than backend logic.

5. Animation and motion behavior is centralized in src/animations and a set of hooks like useLenis, useCursor, useMagnetic, useMousePosition, and useCountUp. This suggests a highly interactive marketing experience with smooth scrolling, pointer effects, and animated sections.

6. The backend surface is exposed through route handlers in src/routes/api. The key flows are:

- api/knowledge.$chatbotId.ingest for uploading or indexing knowledge into a chatbot,

- api/public/chat.$token for serving public chatbot conversations,

- api/webhooks/razorpay for payment events and subscription/billing updates.

7. Chat and retrieval logic are separated into src/lib/api/rag.server.ts and src/lib/api/faq-cache.server.ts. That indicates a retrieval-augmented generation flow: chatbot knowledge is ingested, cached/queried server-side, then used to answer public chat requests.

8. Authentication and persistence are centered on Supabase. The repo includes Supabase client/server helpers, auth middleware/attacher, generated types, and a supabase/migrations folder. This means auth, database schema, and likely row-level security are core architectural boundaries, not just incidental infrastructure.

9. Billing is a distinct subsystem backed by Razorpay, with server-side functions in src/lib/api/billing.functions.ts and a webhook handler. Billing likely gates premium chatbot or dashboard features, and the webhook is the source of truth for payment state changes.

10. Public access vs. authenticated access is an important boundary. Public users can interact with a chatbot via tokenized endpoints or embedded widget code, while authenticated staff manage chatbots, leads, analytics, and settings through the dashboard. The token-based chat route and widget script are the main distribution mechanisms for customer-facing chat.

11. Server/runtime entry points are src/server.ts and src/start.ts, with vite.config.ts and routeTree.gen.ts indicating a modern TypeScript web stack built around file-based routing and server-rendered/API-capable routes.

12. In an architecture diagram, the main boxes should be: marketing site/UI, authenticated dashboard UI, public chat widget, application server/routes, chatbot knowledge/RAG layer, Supabase auth/database, and Razorpay billing/webhooks. The primary data flow is: admin creates chatbot and uploads knowledge → server ingests/indexes data → public widget/chat hits tokenized chat endpoint → response is generated from stored knowledge → billing/auth updates flow through Supabase and Razorpay webhooks.