basith-md/portfolio

This repository contains two related portfolio implementations:

1. a root-level static GitHub Pages site, and

2. a separate React-based portfolio app under portfolio-project/.

For an architecture diagram, treat them as two delivery surfaces with different implementation styles but similar content goals.

1. Root-level site: static, CDN-driven portfolio

• The top-level index.html, style.css, and script.js form a single-page static website.

• The README describes a traditional portfolio with hero/about/skills/projects/contact/footer sections, sticky navigation, scroll animations, and responsive layout.

• Dependencies such as AOS, Font Awesome, and Google Fonts are pulled in externally, so the browser is the runtime and the page behavior is mostly client-side only.

2. Static assets and auxiliary pages

• assets/ holds images and documents used by the site, including the resume PDF and gallery imagery.

• assets/images/gallery/gallery.html suggests a secondary static gallery experience rather than a backend-driven feature.

• .nojekyll indicates GitHub Pages deployment without Jekyll processing, so the root site is intended to be served as-is.

3. React app: separate component-based portfolio

• portfolio-project/ is a React single-page app, likely the more structured implementation.

• Its presence of package.json, src/, public/, reportWebVitals.js, and setupTests.js points to a Create React App-style toolchain.

• tailwind.config.js and postcss.config.js show that styling is at least partially Tailwind/PostCSS-based.

4. Application shell and composition

• src/App.js is the top-level composition point for the React app.

• src/index.js mounts the app into the DOM; src/App.css and src/index.css provide global and app-level styles.

• The app is organized as a sectioned portfolio rather than a routed multi-page application.

5. Content is data-driven

• src/data/experiences.js, projects.js, and personalInfo.js centralize portfolio content.

• This keeps the UI components mostly presentational, with data flowing from these modules into section components.

• That makes the architecture easier to diagram as: data files → section components → rendered portfolio sections.

6. Main section components

• src/components/Sections/ contains the primary page sections: About, Experience, Projects, and Gallery.

• These are likely the major vertical slices of the page and are the main content boundaries for the app.

• The sections probably consume data modules and render reusable UI blocks.

7. Reusable interaction components

• src/components/Cards/ExpandableCard.js is a reusable card pattern, likely used in projects or experience display.

• src/components/UI/RPGTextBox.js suggests a stylized text container that supports the portfolio’s themed presentation.

• These reusable components separate content presentation from section layout.

8. Navigation and user interaction

• src/components/Navigation/SwipeNavigation.js is the main navigation interaction layer in the React app.

• Its name implies gesture-aware navigation, which is important for mobile/touch interaction.

• This is likely the central control for moving between sections, rather than route changes or page reloads.

9. Decorative pixel-art scene as a subsystem

• The src/components/Pixel/ folder contains themed scene elements such as PixelWorld, PixelCat, PixelFireplace, RetroComputer, Bookshelves, DeskArea, and SkillsCoffeeTable.

• These are not just icons; they form a cohesive visual environment, probably the portfolio’s hero/scene area.

• Architecturally, this is a separate visual subsystem that enhances branding and engagement but does not appear to drive core data flow.

10. Utility layer

• src/utils/helpers.js likely contains shared formatting or UI helper logic.

• src/utils/soundfx.js indicates optional audio feedback for interactive elements.

• These utilities sit below the components and support cross-cutting behavior.

11. Public assets and app entry points

• public/index.html, manifest.json, and robots.txt define the app shell and browser metadata.

• The React app is browser-delivered and likely built into static assets for deployment.

• This keeps deployment simple: no server-side runtime is implied.

12. Testing and quality boundaries

• src/App.test.js and src/setupTests.js show that the React app includes a test harness.

• reportWebVitals.js indicates performance metrics support.

• These are supporting boundaries around the UI rather than core product logic.

13. Architectural distinction between the two implementations

• The root site is minimal and static: HTML/CSS/JS enhanced by third-party libraries.

• The React app is modular and data-driven, with reusable components and clearer internal boundaries.

• If diagramming the repo, show them as parallel implementations or a migration path, not as a single unified codebase.

14. Practical system boundary for the repository

• External input is mostly static content: portfolio text, images, resume, and section data.

• Internal processing is entirely client-side rendering and interaction.

• Output is a responsive personal portfolio optimized for GitHub Pages-style static hosting.

If you want the cleanest architecture diagram, model the repo as:

• content/assets,

• a static site delivery path at the root,

• a React SPA under portfolio-project/,

• and shared client-side interaction layers for navigation, animations, and visual presentation.