ishratjahanesha21/programming_learning_esz

1. Overall shape

- This is a Next.js 14 App Router application written in TypeScript.

- The repo is organized around three main surfaces: the marketing/home experience, the authenticated learning area (courses, profile, lessons), and a compiler/playground area backed by an API route.

2. Client/server boundary

- Pages under src/app/**/page.tsx are the route entry points and are mostly server components that decide access and compose the page.

- The interactive UI lives in separate *Client.tsx components and CSS Modules, which handle browser-side state, modals, forms, and user interaction.

- This split is important for the diagram: server pages gate access, while client components render the visible experience and handle events.

3. Authentication subsystem

- Auth is implemented with NextAuth.js v5 via src/auth.ts and the route handler at src/app/api/auth/[...nextauth]/route.ts.

- The README indicates the current login model supports Google, GitHub, and a demo credentials account, with a mock user store for development.

- Session typing is extended in src/types/next-auth.d.ts, so authentication affects both runtime behavior and TypeScript types.

4. Route protection

- Protected areas are primarily /courses/[id] and /profile.

- Protection happens in two layers: server-side checks in page components and edge-level enforcement in src/middleware.ts.

- That means access control is not only a UI concern; it is enforced before the page content renders.

5. Home/marketing experience

- The homepage (src/app/page.tsx) is assembled from reusable sections in src/components/home/*.

- These sections cover the landing narrative: hero, marquee, languages, scenarios, featured courses, compiler teaser, testimonials, FAQ, and CTA.

- The layout shell (src/app/layout.tsx) adds shared chrome via Navbar and Footer.

6. Course discovery and auth gating

- Course cards come from src/components/courses/CourseCard.tsx and the course listing/detail pages under src/app/courses.

- The onboarding behavior is intentional: if the user is not signed in, clicking a course opens the auth modal rather than navigating directly.

- The modal state is shared through src/lib/auth-modal-context.tsx, which acts as a cross-cutting UI state boundary between course cards and the auth UI.

7. Course detail and lesson delivery

- /courses/[id] is the entry into a course detail page, and nested lesson routes live under /courses/[id]/lessons/[lessonId].

- Lesson-specific UI is split into LessonClient.tsx and ProGate.tsx, indicating some lesson content is premium or access-controlled.

- In diagram terms, the course tree is the authenticated content hub, with lesson access potentially constrained further by the “Pro” gate component.

8. Compiler subsystem

- There is a dedicated compiler page under src/app/compiler and a server endpoint at src/app/api/compile/route.ts.

- The architecture suggests a browser-based coding experience where user code is sent to the API route for server-side compilation/execution orchestration.

- This keeps compilation off the client and separates the playground flow from the rest of the learning content.

9. Shared data model

- Most course and language content appears to come from src/lib/data.ts.

- That file is likely the single source of truth for home-page modules, course cards, lesson metadata, and language lists.

- For the architecture diagram, this is the repo’s main content/data boundary: content is centralized and then consumed by multiple route trees and sections.

10. Styling and design system

- Styling is handled with CSS Modules per component plus src/styles/globals.css for shared tokens and utilities.

- The README calls out a “Playful Geometric” design system, so visual consistency is achieved through shared tokens rather than a heavy component framework.

- Fonts and iconography are also part of the visual layer: Outfit and Plus Jakarta Sans, plus Devicons via CDN.

11. External services and infrastructure

- The only clearly material external service in the current architecture is NextAuth-backed OAuth providers: Google and GitHub.

- The repo includes src/lib/supabase.ts and src/lib/db.ts, but the README says persistence is still mock/in-memory and real database integration is future work.

- So the current production shape is mostly stateless app-server logic plus auth provider callbacks, not a fully database-driven backend.

12. Operational boundaries

- Public assets live under public/, including the main preview image.

- next.config.js, middleware.ts, and the API routes are the key runtime boundaries to show in a diagram: request routing, auth interception, and server-side execution.

- The app is deployable as a typical Next.js app on Vercel, but the current architecture is still centered on app routes, auth, and static content composition rather than a separate backend service.