shadmansshuvo/edu-verse

1. Overall shape

- This is a Next.js App Router monolith with clear route-group boundaries: app/(auth) for sign-in/sign-up, and app/(main) for the product experience.

- Most business logic is split between server-rendered pages, co-located server actions (actions.ts), and API route handlers under app/api.

2. Primary product areas

- The main application is organized around the platform’s core domains: courses, modules, exams, dashboard, my-courses, profile, settings, contact, and admin/instructor views.

- Each domain has its own page entrypoints and often domain-specific components, which keeps feature boundaries visible in the file structure.

3. Role-based access control boundary

- The app is explicitly role-driven: Student, Instructor, and Administrator each have separate pages and dashboards.

- middleware.ts is the main gatekeeper for route protection and likely enforces session presence and role access before the request reaches pages or APIs.

4. Authentication and session model

- Authentication is custom rather than outsourced: lib/auth.ts, lib/session.ts, and lib/password.ts indicate HTTP-only cookie sessions with local password handling.

- Auth flows are handled in app/(auth)/signin and app/(auth)/signup, with server actions performing the actual credential/session mutations.

5. Database architecture

- Data access is organized as a raw SQL layer, not an ORM: the db/ directory is split by entity (courses.ts, modules.ts, exam.ts, orders.ts, users.ts, etc.).

- db/schema.psql defines the relational schema, while db/schemas.ts and lib/validators/* provide validation boundaries for request and form data.

- The persistent model spans users/roles/permissions, course content, enrollments/orders/payments, exams/attempts/responses, reviews/comments, chat history, notifications, and settings.

6. Course/content delivery flow

- The learning experience centers on course → module → material relationships.

- Course pages and module pages render content and learning tools, while mutations such as adding materials, managing modules, and enrolling students are handled by page-local actions or API routes.

- Shared components like lesson player, material item, add-material form, and review form sit outside the route tree and are reused across content views.

7. Exams and assessment subsystem

- Exams are modeled as a separate domain with student and instructor experiences.

- Students interact through exam dashboards, exam forms, and result pages; instructors use list and view components to manage exams and inspect attempts.

- The presence of attempt, question, and response database modules shows the assessment flow is persisted end-to-end, not computed client-side.

8. Payments and enrollment lifecycle

- Paid enrollment is a first-class workflow: the payment subtree includes initiate, success, fail, and cancel routes, plus an IPN webhook.

- lib/sslcommerz.ts is the payment integration layer, so the payment provider is external, but state reconciliation is local through API callbacks and database writes.

- Enrollment and order records are therefore coupled to payment status and course access control.

9. Media and video subsystem

- Video delivery is backed by Mux, with dedicated routes for upload URL generation, sync, and Mux webhooks.

- lib/mux.ts and lib/storage.ts suggest a hybrid media pipeline: upload/asset management is externalized, while course materials and metadata are tracked in PostgreSQL and/or Supabase Storage.

10. AI features

- There are two AI-facing capabilities: an AI chat assistant and an AI quiz generator.

- These are isolated behind API routes (app/api/ai/...) and surfaced in reusable client components like ai-chat-widget and auto-quiz-generator.

- Chat history and cleanup are explicit backend concerns, implying persistence rather than ephemeral prompt handling.

11. Dashboard, analytics, and admin operations

- The dashboard area aggregates platform activity into stats, progress lists, recent attempts, and course/exam summaries.

- app/(main)/admin and app/(main)/instructor separate governance from teaching operations, with backend support in db/admin.ts, db/dashboard.ts, db/instructor.ts, and related entity modules.

- This suggests analytics are precomputed or query-driven from PostgreSQL rather than from a separate analytics service.

12. Shared UI and presentation layer

- components/ contains cross-cutting UI: navigation, footer, search, theme support, loaders, skeletons, modals, and animated primitives.

- The app uses modern front-end presentation tooling, but these components are still secondary to the server/data architecture; they mainly shape how route-level data is displayed.

13. Infrastructure and integration boundaries

- The repo’s external dependencies that materially affect architecture are PostgreSQL, Mux, SSLCommerz, and Supabase Storage.

- The app also exposes operational routes such as setup-admin, search suggestions, and sitemap generation, which show the project is designed for both runtime functionality and platform bootstrapping.

14. Data flow summary

- Typical request path is: browser page/component → server action or API route → db layer / external service → PostgreSQL response or webhook-backed update → UI re-render.

- The architecture is optimized for server-side authority: access control, business rules, payment state, media sync, and AI persistence all converge on backend routes and the SQL layer.