ht1makcv5-create/portfolio

Purpose and Workspace Shape

This is a pnpm TypeScript monorepo for a portfolio/contact-request system: a Vite/React portfolio frontend, a Node API server, shared OpenAPI-derived clients/validation, and a Drizzle database layer. The active application artifacts appear to be under artifacts/boohx and artifacts/api-server; artifacts/portfolio-site and artifacts/mockup-sandbox are separate frontend artifacts/snapshots.

Key workspace roots: package.json, pnpm-workspace.yaml, tsconfig.base.json.

Frontend Application

The primary frontend is a Vite React single-page portfolio application. Browser bootstrapping flows from main.tsx into App.tsx, with the portfolio page and visual components rendered from there.

Paths:

• artifacts/boohx/src/main.tsx

• artifacts/boohx/src/App.tsx

• artifacts/boohx/src/pages/portfolio.tsx

It has a GitHub Pages-oriented Vite configuration in addition to its standard Vite config:

• artifacts/boohx/vite.config.ts

• artifacts/boohx/vite.config.ghpages.ts

HTTP API Service

The backend is a standalone TypeScript API server, with process startup separated from application composition. Route registration is centralized, then delegated by concern: health checks, incoming portfolio/contact requests, visitor recording, and admin operations.

Paths:

• artifacts/api-server/src/index.ts

• artifacts/api-server/src/app.ts

• artifacts/api-server/src/routes/index.ts

Primary route boundaries:

• artifacts/api-server/src/routes/requests.ts

• artifacts/api-server/src/routes/visits.ts

• artifacts/api-server/src/routes/admin.ts

• artifacts/api-server/src/routes/health.ts

Request, Analytics, and Admin Flow

Public clients submit request records and visit events to the API. The API persists these through the shared database package. Admin endpoints expose operational access to requests/dashboard data and use a dedicated admin-session implementation rather than treating public requests as authenticated admin traffic.

Paths:

• lib/db/src/schema/requests.ts

• lib/db/src/schema/visits.ts

• artifacts/api-server/src/lib/admin-session.ts

The OpenAPI contract names the core domain types: requests, request updates/statuses, visits, dashboard data, admin sessions, and Telegram login/bot structures. This contract is the intended API boundary between UI and backend:

• lib/api-spec/openapi.yaml

• lib/api-zod/src/generated/api.ts

Shared Contract and Persistence Layer

lib/api-spec is the source API specification; generated Zod types provide runtime validation/type sharing, while the React client package provides generated API calls and a customizable fetch boundary. Database access and schema ownership are isolated in lib/db, configured for Drizzle.

Paths:

• lib/api-client-react/src/generated/api.ts

• lib/api-client-react/src/custom-fetch.ts

• lib/db/src/index.ts

• lib/db/drizzle.config.ts

This separation allows frontend callers to depend on generated contract code rather than API-server internals, and keeps persistence details out of route modules.

Telegram Integration and Operational Services

The backend includes explicit Telegram and Telegram-bot integrations, likely used for request notifications and/or admin authentication flows defined in the API contract. Logging is also isolated as an infrastructure concern.

Paths:

• artifacts/api-server/src/lib/telegram.ts

• artifacts/api-server/src/lib/telegram-bot.ts

• artifacts/api-server/src/lib/logger.ts

External/runtime boundaries are therefore: browser-to-HTTP API, API-to-database through Drizzle, and API-to-Telegram.

Deployment and Build

The repository includes Railway deployment metadata and documentation, a GitHub deployment workflow, and Replit artifact descriptors. The API has its own build script, indicating it is deployed/built independently from frontend artifacts.

Paths:

• railway.json

• RAILWAY_DEPLOY.md

• .github/workflows/deploy.yml

• artifacts/api-server/build.mjs