How savazar01/wedplanai works
1. Overall shape
- This is a single Next.js 16 full-stack monolith: the same repo serves public pages, authenticated dashboard pages, server actions, and the auth API.
- There is no separate backend service layer; business logic is split across App Router pages, server actions, and a Drizzle/PostgreSQL data layer.
2. Primary runtime boundary
- The app runs as a Node.js web container connected to a PostgreSQL database.
- Deployment is designed around Docker Compose: one container for the web app and one for Postgres, with migrations applied during startup.
3. Public-facing entry points
- src/app/page.tsx is the landing page.
- src/app/login, src/app/signup, and src/app/wizard handle unauthenticated onboarding and account creation.
- src/app/wedding/[id]/page.tsx is the public wedding showcase page, which exposes wedding-specific content such as countdown, itinerary, and RSVP entry.
4. Authenticated application shell
- src/app/dashboard/layout.tsx wraps the main private area with the dashboard shell.
- Components like SidebarShell, DashboardHeader, and WeddingSwitcher indicate a workspace-centric UI where the current wedding is the main context.
- The dashboard is divided into functional sections: calendar, guests, kanban, timeline, settings, users, and vendors.
5. Authentication and session flow
- Authentication is handled through Better Auth.
- src/app/api/auth/[...all]/route.ts is the auth API entry point.
- src/lib/auth-client.ts, src/lib/auth-server.ts, and src/lib/auth.ts provide client/server auth helpers.
- src/proxy.ts and the presence of protected dashboard routes imply route-level access control for authenticated areas.
6. Core domain model: weddings as the tenant
- The repo is organized around a wedding workspace concept rather than a generic project board.
- src/app/wedding/[id], src/components/dashboard/WeddingSwitcher.tsx, and src/lib/wedding-helper.ts suggest that nearly all app data is scoped to a selected wedding.
- The dashboard supports switching between weddings, which is the main multi-tenant boundary in the product.
7. Guest management flow
- Guest management lives in src/app/dashboard/guests with supporting components in src/components/guests.
- Server actions in src/app/actions/guests.ts likely handle create/update/import operations.
- src/components/guests/csv-upload.tsx and public/sample-guests.csv show an import pipeline for bulk guest onboarding.
- The public RSVP form in src/components/wedding/public-rsvp-form.tsx closes the loop from public invite page back into the guest database.
8. Planning and execution views
- src/app/dashboard/kanban and src/components/kanban/board.tsx implement the planning board for task/status tracking.
- src/app/dashboard/calendar plus src/components/calendar/MonthCalendarOnly.tsx, TimelineOnly.tsx, and coordinator.tsx provide the date-oriented planning views.
- These views are separate UI surfaces but likely share wedding-scoped data from the same database.
9. Vendors and budget tracking
- src/app/dashboard/vendors and src/components/vendors manage vendor records and budget values.
- The README indicates contract value, paid amount, and currency handling, so this is a distinct financial subdomain rather than just a contact list.
10. Administration and settings
- src/app/dashboard/users and its actions.ts file handle role-based user management for admins inviting collaborators.
- src/app/dashboard/settings plus ChangePasswordForm.tsx cover account/workspace settings and password changes.
- This is the boundary for administrative operations versus day-to-day wedding planning.
11. Data layer and persistence
- src/db/schema.ts is the canonical schema definition; src/db/migrations/* are the generated SQL migrations.
- src/db/client.ts is the database access point, while src/db/migrate.ts and src/db/reset.ts support lifecycle operations.
- src/lib/seed-sample-wedding.ts suggests the app can bootstrap demo data for onboarding or local development.
12. Server action architecture
- The src/app/actions/* directory centralizes mutation logic by domain: auth, calendar, guests, kanban, vendors, wedding, and wizard.
- This creates a clear split: UI components collect input, server actions mutate state, and Drizzle/Postgres persists it.
- For an architecture diagram, these actions are the main write-path boundary between client interactions and the database.
13. Operational concerns
- docker-compose.yml, Dockerfile, .env.example, and the README deployment notes show that the app expects explicit environment configuration for auth and DB access.
- src/instrumentation.ts indicates runtime instrumentation hooks, likely for observability or startup logging.
- src/app/globals.css, Tailwind/shadcn UI components, and the public assets folder support the presentation layer but do not define core architecture.
Main entry points: actions Server actions · layout.tsx Dashboard shell · client.ts DB client · page.tsx Landing
Components 24
Public app
Unauthenticated entry points and wedding showcase pages.
- Landing · Public homepage.
src/app/page.tsx - Login · Sign-in entry.
src/app/login/page.tsx - Signup · Account creation entry.
src/app/signup/page.tsx - Wizard · New wedding setup flow.
src/app/wizard/page.tsx - Wedding page · Public wedding details, countdown, itinerary, and RSVP.
src/app/wedding/[id]/page.tsx
Dashboard
Authenticated workspace shell and feature areas scoped to a wedding.
- Dashboard shell · Authenticated workspace layout wrapper.
src/app/dashboard/layout.tsx - Dashboard home · Private landing page for the workspace.
src/app/dashboard/page.tsx - Calendar · Date-oriented planning surface.
src/app/dashboard/calendar/page.tsx - Guests · Guest management workspace.
src/app/dashboard/guests/page.tsx - Kanban · Task and status tracking board.
src/app/dashboard/kanban/page.tsx - Timeline · Schedule and milestone view.
src/app/dashboard/timeline/page.tsx - Vendors · Vendor and budget management.
src/app/dashboard/vendors/page.tsx - Settings · Workspace and password settings.
src/app/dashboard/settings/page.tsx - Users · Collaborator and role administration.
src/app/dashboard/users/page.tsx
Server logic
Auth, access control, and mutation paths.
- Auth API · Authentication endpoint surface.
src/app/api/auth/[...all]/route.ts - Server actions · Domain write-paths for auth, planning, guests, vendors, and onboarding.
src/app/actions - Auth helpers · Shared Better Auth client and server utilities.
src/lib/auth.ts - Route guard · Middleware-like protection for authenticated routes.
src/proxy.ts - Wedding helper · Wedding-scoped context and selection logic.
src/lib/wedding-helper.ts
Data layer
Persistence, schema, and operational lifecycle.
- DB client · Database connection and query entry point.
src/db/client.ts - Schema · Canonical Postgres schema definitions.
src/db/schema.ts - Migrations · Generated database migrations.
src/db/migrations/0003_round_alex_wilder.sql - DB lifecycle · Migration and reset helpers for local and startup workflows.
src/db/migrate.ts - Sample seed · Demo wedding data bootstrap.
src/lib/seed-sample-wedding.ts
Connections 32
- Landing → Login: start · Public users can move to sign-in.
- Landing → Signup: create account · Public users can create an account.
- Landing → Wizard: onboard · New users can enter the setup flow.
- Signup → Wizard: next · Account creation leads into workspace setup.
- Dashboard shell → Dashboard home: wraps · Private shell frames the dashboard home.
- Dashboard shell → Calendar: contains · Shell hosts planning sections.
- Dashboard shell → Guests: contains · Shell hosts planning sections.
- Dashboard shell → Kanban: contains · Shell hosts planning sections.
- Dashboard shell → Timeline: contains · Shell hosts planning sections.
- Dashboard shell → Vendors: contains · Shell hosts planning sections.
- Dashboard shell → Settings: contains · Shell hosts account controls.
- Dashboard shell → Users: contains · Shell hosts admin controls.
- Wedding page → Server actions: rsvp/update · Public wedding interactions can submit mutations.
- Auth API → Auth helpers: uses · Auth route is backed by shared auth utilities.
- Route guard → Auth helpers: checks session · Protected routes rely on auth state helpers.
- Server actions → Auth helpers: auth · Mutations validate identity and session context.
- Server actions → Wedding helper: scope · Write operations are scoped to a selected wedding.
- Server actions → DB client: persist · Server actions write through the database client.
- Wedding helper → DB client: load context · Wedding context is resolved from persisted data.
- DB client → Schema: maps to · Client queries follow the schema contract.
- Schema → Migrations: materializes · Schema is applied through generated migrations.
- DB lifecycle → Migrations: runs · Lifecycle scripts apply database changes.
- Sample seed → DB client: seeds · Demo data bootstrap writes into the database.
- Dashboard home → Wedding helper: context · Dashboard home depends on the active wedding.
- Calendar → Server actions: mutations · Calendar UI saves changes through actions.
- Guests → Server actions: mutations · Guest management uses server actions.
- Kanban → Server actions: mutations · Kanban updates go through server actions.
- Vendors → Server actions: mutations · Vendor updates go through server actions.
- Users → Server actions: admin writes · User administration uses server-side mutations.
- Settings → Server actions: updates · Settings changes are persisted through actions.
- Auth API → DB client: sessions · Auth state ultimately persists in the database.
- Route guard → Dashboard shell: protects · Authenticated dashboard routes are guarded.