whoisyurii/checkmygit

1. Overall shape

- This is a SvelteKit 2 / Svelte 5 app deployed to Cloudflare Pages.

- It is not just a marketing site: it has a public landing experience, a per-user portfolio generator, “explore” analytics pages, and several JSON/image API endpoints.

2. Primary product flow: GitHub username → portfolio

- The core experience lives under src/routes/[username].

- A request for a username is handled by +page.server.ts, which fetches and shapes GitHub data, then +page.svelte renders one of several templates.

- The portfolio is composed from reusable sections in src/lib/components/portfolio and src/lib/components/templates, with the selected template controlled by query state such as template=bento.

3. GitHub data access layer

- src/lib/server/github.ts is the main integration boundary with GitHub.

- The README says GitHub GraphQL is the primary source, with REST fallback when needed.

- Shared data shapes live in src/lib/types/github.ts, portfolio.ts, rankings.ts, trending.ts, and globe.ts, which indicates the app normalizes external API data before it reaches UI components.

4. Server-side feature modules

- The src/lib/server directory contains most of the app’s business logic:

- rankings.ts and trending.ts back the public rankings/trending features.

- globe.ts and geo/* support location-based visualization, including geocoding and country centroid lookup.

- kv/* provides Cloudflare KV-backed caching, deduplication, retry logic, and counters.

- This separation makes the server layer the boundary for rate-limit-sensitive and cache-sensitive operations.

5. Caching, counters, and persistence on Cloudflare

- The src/lib/server/kv submodule strongly suggests the app uses Cloudflare KV for lightweight persistence.

- It appears to support:

- cached API responses,

- deduplicating repeated events,

- global/view counters,

- retry helpers for external calls.

- This is important architecturally because it reduces GitHub API pressure and enables aggregate metrics such as views and global counters.

6. Public API surface

- src/routes/api/* exposes backend functionality to the browser and to external consumers:

- /api/rankings

- /api/trending

- /api/view

- /api/og/[username]

- These endpoints likely reuse the same server modules as the page loaders, so the app has a shared data layer serving both HTML and JSON/image responses.

7. Explore subsystem

- src/routes/explore is a dedicated analytics/discovery area with subpages for:

- globe

- rankings

- trending

- Each has its own +page.server.ts, so the explore views are server-rendered and data-driven rather than purely client-side.

- UI components under src/lib/components/explore, rankings, and globe suggest these pages are built from table/filter/chart widgets and, for the globe, geographic visualization.

8. Landing, marketing, and navigation

- The root route (src/routes/+page.svelte) and src/lib/components/landing/* implement the homepage: hero, feature highlights, screenshot showcase, and CTA.

- Shared layout pieces in src/lib/components/layout provide the header/footer, logo, search, actions, and controls.

- The header likely acts as the main navigation entry point into username lookup and explore pages.

9. Reusable UI kit

- src/lib/components/ui contains the low-level design system: buttons, cards, badges, inputs, dropdowns, skeletons, tabs, toast, theme toggle, QR modal, and table primitives.

- This is the styling and interaction foundation used across landing, portfolio, rankings, and explore pages.

- The presence of LoadingTransition, Skeleton, and multiple *Skeleton.svelte components indicates the app is designed around asynchronous server data with polished loading states.

10. Portfolio export and sharing

- src/lib/components/export and src/lib/utils/export.ts support turning a rendered portfolio into an image.

- The README explicitly calls out PNG export via html-to-image.

- QRModal and the shareable URL pattern suggest the app is optimized for link sharing and image capture, not just on-screen viewing.

11. Client-side state and presentation helpers

- src/lib/stores/* contains Svelte stores for navigation, theme, GitHub stars, and generation state.

- These stores are the main client-side state boundary; they keep cross-component UI state out of the server loaders.

- src/lib/utils/* contains pure helpers for GitHub data transformation, JSON-LD generation, QR encoding, and export support.

12. SEO, metadata, and static delivery

- src/routes/sitemap.xml/+server.ts and src/lib/utils/jsonld.ts show SEO is treated as a first-class concern.

- Static files in static/ include robots.txt and a web manifest, reinforcing that the app is optimized for discoverability and PWA-style presentation.

- The OG image endpoint under /api/og/[username] also supports social sharing previews.

13. Deployment/runtime boundary

- The presence of wrangler.toml and Cloudflare-specific KV modules indicates the app is designed to run in a Cloudflare edge/serverless environment.

- That choice materially shapes the architecture: lightweight server functions, external API calls, and KV-based caching/persistence instead of a traditional long-lived backend.

14. How to draw the diagram

- A useful diagram should show:

- browser requests entering SvelteKit routes,

- server loaders/API endpoints calling GitHub and geo services,

- Cloudflare KV sitting behind caching/counters,

- shared UI components rendering landing, portfolio, and explore pages,

- export/share endpoints producing PNG/OG assets.

- The main architectural boundary is presentation (Svelte components/routes) versus server data orchestration (src/lib/server + API routes + KV + GitHub).