bytepute/website

1. Project shape

- This is a Next.js App Router application built as a small content management site for articles, with a public reading surface and an admin editing surface.

- The repo is organized around route segments in app/, shared UI in components/, and database/domain logic in lib/ plus Prisma schema/migrations.

2. Route topology

- Public routes:

- app/page.tsx — landing page

- app/articles/page.tsx — article index

- app/articles/[slug]/page.tsx — article detail page

- Admin routes:

- app/admin/page.tsx — admin entry/dashboard

- app/admin/articles/new/page.tsx — create article

- app/admin/articles/[id]/edit/page.tsx — edit article

- This is a route-driven architecture rather than a separate frontend/backend split.

3. Content domain

- The central domain model is Article.

- The article lifecycle is: list → read → create → edit.

- The naming (slug for public detail pages, id for admin edit pages) suggests a clear boundary between public URL identity and internal database identity.

4. Data access layer

- lib/articles.ts is the main domain/data access module for article operations.

- lib/prisma.ts centralizes the Prisma client, so database access is funneled through a single ORM boundary.

- prisma/schema.prisma and the migration files define the persistence model and its evolution, making the database a first-class part of the architecture.

5. Admin mutation flow

- app/admin/actions.ts indicates the admin side uses server actions for mutations rather than a separate REST API.

- The likely flow is: admin form submits → server action runs on the server → Prisma writes to the database → updated article data is revalidated/rendered.

- This keeps write operations close to the route that owns them and avoids an extra API layer.

6. Public read flow

- Public article pages are read-only consumers of the article domain.

- components/articles-list.tsx, components/article-detail.tsx, and components/article-content.tsx separate the list/detail rendering concerns from the route files.

- The public side is therefore “route composes data + presentation components,” with data coming from the shared article layer.

7. Admin UI boundary

- components/admin-gate.tsx and proxy.ts are the main protection mechanisms around admin routes.

- lib/auth.ts likely contains auth/session checks, while the gate component controls rendering access inside the UI and the proxy enforces route-level protection.

- This creates a distinct boundary between anonymous public browsing and privileged content management.

8. Forms and editing UX

- components/article-form.tsx and components/edit-article-panel.tsx are the main edit/create interfaces.

- These components are reused by the new/edit admin pages, so the form logic is shared and the route files stay thin.

- The admin UI is therefore centered on a reusable form/editor component rather than page-specific form implementations.

9. Shared presentation system

- The app uses a component library based on shadcn/ui with primitives in components/ui/ (button, input, label, textarea).

- components/site-header.tsx, components/loading-fallbacks.tsx, and components/theme-provider.tsx support cross-cutting app presentation concerns.

- app/layout.tsx and app/globals.css provide the global shell and styling foundation for both public and admin areas.

10. Runtime and persistence boundaries

- The application runs as a single Next.js server/client app; there is no separate backend service or standalone API project in the tree.

- Persistence is handled through Prisma + a relational database, with migrations in prisma/migrations/.

- That means the major boundaries are:

- browser UI

- Next.js route/server-action layer

- auth/protection layer

- Prisma-backed data layer

- database

11. What to show in an architecture diagram

- A good diagram should show:

- Public routes feeding shared article display components

- Admin routes feeding form/editor components

- Admin requests passing through auth/protection before mutations

- Server actions and lib/articles/lib/prisma as the bridge to the database

- Prisma schema/migrations as the persistence contract

- The key architectural idea is a single Next.js application with strong separation between public read paths and protected admin write paths.