adilmunawar/adilportfolio

1. Repository shape

This is a Next.js App Router portfolio site written in TypeScript. The architecture is mostly static/content-driven rather than database-driven: the homepage is assembled from reusable React sections, while a small server API handles chat.

2. Application shell

The core app lives under src/app/. layout.tsx provides the global frame, page.tsx is the portfolio landing page, and globals.css defines shared styling. robots.ts, sitemap.ts, and manifest.ts show that the site is designed for search indexing and PWA-style metadata support.

3. Homepage composition

The landing page is built as a section-based composition from src/components/. Major content areas include hero, skills, services, projects, case studies, blog, certifications, testimonials, stats, contact, badges, and achievements. This makes the page a modular aggregator rather than a monolithic template.

4. UI component boundary

src/components/ui/ contains a large set of reusable primitives and compound widgets, likely based on the shadcn/Radix pattern. These are the low-level building blocks used by the higher-level portfolio sections, keeping presentation concerns isolated from content assembly.

5. Content/data layer

src/lib/ is the main content store for the site. It contains JSON-backed datasets such as blog-data.json, case-studies.json, github-contributions.json, and leetcode-stats.json, plus shared helpers in utils.ts. Most “dynamic” content is therefore file-backed and build-time friendly, not fetched from a database at runtime.

6. Static asset boundary

public/ holds images, badges, certifications, testimonials, blog graphics, and site files like robots.txt, llm.txt, and llms.txt. This suggests the site serves a mix of portfolio media and crawler/AI consumption metadata directly from static hosting.

7. Interactive assistant subsystem

The src/components/Zenith/ area and src/app/api/chat/route.ts form a separate conversational feature. The UI side likely renders the assistant/orb/chat experience, while the API route is the server boundary for chat requests. This is the only clearly visible backend-style interaction point in the repo.

8. Stats and external profile integration

Dedicated components for GitHub and LeetCode stats (GitHubStats.tsx, LeetCodeStats.tsx, badges/showcase sections) indicate that the site surfaces external developer-profile data. The data itself is stored locally in JSON, so the runtime UI reads precomputed snapshots rather than querying live services on every page load.

9. Automation and regeneration pipeline

The scripts/ folder and GitHub Actions workflows under .github/workflows/ create an update pipeline for contribution stats, LeetCode stats, and year-based content. The flow is: automation script or workflow → regenerated artifacts/templates → committed JSON/assets → rendered by React components.

10. Client-side helpers

src/hooks/use-mobile.tsx and src/hooks/use-toast.ts provide small cross-cutting client behaviors such as responsive detection and toast state. These are utility boundaries rather than core business logic.

11. Styling and visual system

Styling is split between Tailwind configuration, global CSS, and component-scoped CSS files such as ProfileCard.css and LogoLoop.css. The design system is clearly tuned for a polished portfolio look with animated/interactive sections, but the architectural emphasis remains on reusable composition.

12. Important diagram takeaway

For an architecture diagram, the key distinction is: static portfolio content + generated profile stats + one chat API endpoint. There is no visible separate database, queue, or microservice layer; instead, the repo centers on a Next.js frontend that consumes local content files and a lightweight server route for conversational interaction.