kodeinkgp-technology-web-3-0-society/kik-nextjs

1. Overall shape

- This is a Next.js App Router site for the KodeinKGP student society.

- The repository combines a public marketing/content site with several interactive subsystems: deKodeX, PDS practice/lab, articles, events, leaderboard, auth/registration, and team pages.

2. Front-end composition

- UI is split between src/Components/ and route-level page files under src/app/.

- src/Components/ holds reusable presentation blocks such as the navbar, footer, landing sections, auth forms, loaders, buttons, cards, and deKodeX-specific UI.

- src/app/ provides the actual routed screens and stitches those components together.

3. Routing and page boundaries

- The top-level routes include landing/home, articles, events, teams, tech-triad, auth, registration, summary, leaderboard, PDS, and deKodeX.

- Dynamic routes are used where content is indexed by an identifier, especially:

- src/app/dekodeX/[QuestionID]/

- src/app/leaderboard/[page]/

- src/app/pds/lab/[topic]/[subTopic]/[ind]/

- This indicates a content-driven UI where each route is backed by structured data rather than hardcoded screens.

4. deKodeX challenge system

- src/app/dekodeX/ is the most application-like subsystem.

- It includes a problem arena, modal dialogs, leaderboard view, per-question pages, and loading states.

- Supporting API routes handle the challenge lifecycle: auth, question retrieval, submission, leaderboard, Turnstile verification, and certificate issuance/checking.

5. Backend boundary and external services

- src/backend/firebase.js and src/backend/firebaseAdmin.js show a split between client Firebase usage and server/admin Firebase access.

- requireAuth.js and middleware.js suggest route-level protection for authenticated flows.

- The use of Cloudflare Turnstile is explicit via verifyTurnstile, indicating bot protection on sensitive endpoints like submission/auth.

6. Data model and content sources

- Much of the site is data-driven from JSON and static files in src/data/ and public/data/.

- src/data/ contains curated content for articles, events, teams, animations, and PDS question banks.

- public/data/ and public/testcases.json appear to store challenge inputs, outputs, or downloadable artifacts used by deKodeX/PDS features.

- This means the app often renders from local structured content instead of a remote CMS.

7. PDS subsystem

- src/app/pds/ is a separate learning/practice area with theory and lab sections.

- The lab section is hierarchical and topic/subtopic-driven, with components for lab cards, questions, subtopics, and a login modal.

- This subsystem likely serves problem-solving content from local JSON question banks and is distinct from deKodeX in both UX and content structure.

8. Articles and media

- src/app/articles/ and public/article support article browsing with animation wrappers and related data files.

- The project uses Lottie animations heavily, with JSON assets in src/data/animations/ and article-specific animation metadata in src/data/articles/.

- Static images for events and articles are stored under public/, keeping rich media separate from code.

9. Authentication and user state

- src/app/auth/ and src/Components/Auth/ implement sign-in/sign-up UI.

- src/contexts/authContext.jsx plus src/hooks/useAuthToken.js indicate shared client-side auth state and token handling.

- src/backend/requireAuth.js and protected API routes show that auth is enforced both in the UI and on the server side.

10. Operational tooling and migration

- The backup/ folder contains a Firestore migration script, suggesting an earlier or ongoing data migration path.

- src/backend/runtimeCache.js implies server-side caching for performance or rate-sensitive lookups.

- netlify.toml shows the app is intended to deploy on Netlify, even though it is built with Next.js.

11. Styling and build setup

- Styling uses Tailwind CSS with supporting PostCSS and global CSS.

- next.config.mjs, tailwind.config.js, and eslint.config.mjs define the build/runtime and code-quality boundaries.

- The codebase is organized as a typical Next.js application with static assets in public/, app routes in src/app/, and shared logic in src/backend/ and src/contexts/.

12. How data flows through the system

- Static content and JSON are loaded into route components for most public pages.

- Interactive features such as deKodeX and auth move through API routes, which then access Firebase/admin services and return computed state such as validation, submissions, leaderboard data, or certificates.

- The architecture is therefore a mix of static content delivery and server-backed interactive workflows centered around Firebase.