How elyse502/project-management works
1. High-level shape
- This is a split full-stack app with a React/Vite client and an Express/Node server.
- The server owns business logic, authorization, persistence, email delivery, and background jobs.
- The client is a single-page application that renders workspace/project/task workflows and talks to the server over HTTP.
2. Frontend boundary
- The client/ app is organized as a classic SPA: main.jsx bootstraps App.jsx, which is composed into route-level pages under src/pages/.
- Reusable UI is concentrated in src/components/, with distinct components for dashboards, project views, task dialogs, sidebars, analytics, calendar, and member management.
- Styling is handled with Tailwind-based frontend tooling, and state is split between UI state and domain state through Redux Toolkit slices in src/features/ plus the central store in src/app/store.js.
3. Client data access
- The frontend’s backend integration is centralized in src/configs/api.js, which is the main boundary for calling the server API.
- The client also integrates Clerk on the UI side via environment-configured publishable keys, so authentication state and org context are available to the app before it issues protected API calls.
4. Frontend feature areas
- The page set maps cleanly to the product’s core domains: Dashboard, Projects, ProjectDetails, TaskDetails, Team, and a shared Layout.
- The component list shows the main user flows: creating projects/tasks, inviting members, switching workspaces, viewing analytics, checking calendars, and reviewing recent activity.
- workspaceSlice.js and themeSlice.js suggest the app’s key cross-cutting UI concerns are workspace selection and dark/light theme state.
5. Backend API surface
- The server is an Express application defined in server/server.js, with route modules for workspace, project, task, and comment resources.
- Controllers contain the business logic for each domain, while middlewares/authMiddleware.js protects routes and enforces access rules.
- This separation indicates a resource-oriented API where the frontend consumes workspace-scoped endpoints for almost all operational behavior.
6. Authorization and tenancy
- Clerk is the identity provider, but the server is responsible for enforcing access to workspace/project data.
- The architecture is multi-tenant: organizations/workspaces isolate data, and membership determines what a user can see or mutate.
- That means the main trust boundary is between Clerk-authenticated identity on the client and server-side authorization checks on workspace-scoped records.
7. Persistence layer
- Prisma is the ORM, and PostgreSQL is the backing database, with Neon called out in the README as the hosted database provider.
- The authoritative schema is in server/prisma/schema.prisma; the README’s model list shows the core entities: user, organization/workspace, member, project, task, comment, and notification.
- The data model is centered on collaboration: projects belong to workspaces, tasks belong to projects, and comments/notifications attach to task and user activity.
8. Collaboration and communication
- The server includes configs/nodemailer.js, so email is a first-class part of the architecture rather than an afterthought.
- Invites, task assignment notifications, and due-date reminders are all part of the system’s collaboration loop.
- These notifications connect user actions in the app to asynchronous outbound communication outside the core request/response path.
9. Background job subsystem
- server/inngest/ shows event-driven background processing via Inngest.
- According to the README, this handles email notifications, reminder emails, Clerk webhook syncing, and analytics processing.
- Architecturally, this creates a second execution path besides the API: events are emitted from app activity, then processed asynchronously for side effects and reporting.
10. Product analytics and reporting
- The presence of ProjectAnalytics, StatsGrid, RecentActivity, and TasksSummary in the client indicates the UI consumes precomputed or aggregated project metrics.
- That pairs with the backend’s analytics-processing jobs, implying a pipeline where task/project events are stored in the database and later summarized for dashboard views.
11. Operational deployment
- Both client/ and server/ have vercel.json, so they are intended to be deployed as separate Vercel targets.
- The frontend is a static SPA build, while the backend is a serverless-compatible Express API with Prisma-generated database access.
- Environment variables are used to bind the deployment to Clerk, Neon/PostgreSQL, Inngest, and SMTP services.
12. What matters most for an architecture diagram
- Draw three main zones: React client, Express API, and PostgreSQL/Prisma data layer, then attach Clerk for auth and Inngest + SMTP for async notifications.
- Show the client as the presentation and interaction layer, the server as the domain/business layer, and the database as the source of truth for workspaces/projects/tasks/comments.
- The key flows are: user authenticates via Clerk, client calls protected API endpoints, server validates membership and mutates Prisma models, and background jobs send email/process analytics after events are persisted.
Main entry points: App.jsx App · controllers Controllers · index.js Inngest jobs · routes Routes
Components 20
Client
React/Vite single-page app and UI state
- main.jsx · Bootstraps the React app
client/src/main.jsx - App · Top-level application composition
client/src/App.jsx - Pages · Dashboard, projects, task, team, and layout screens
client/src/pages - Components · Reusable workspace, project, task, analytics, and navigation components
client/src/components - Store · Central UI and domain state container
client/src/app/store.js - Slices · Workspace and theme state
client/src/features - API client · Centralized server API access
client/src/configs/api.js - Workspace UI · Workspace switcher, dashboards, project/task dialogs, and member management
Server
Express API, business logic, and authorization
- server.js · API server bootstrap and routing
server/server.js - Routes · Workspace, project, task, and comment endpoints
server/routes - Controllers · Business logic for resource operations
server/controllers - Auth middleware · Protects workspace-scoped routes and access rules
server/middlewares/authMiddleware.js - Prisma client · Database access configured for the server
server/configs/prisma.js - Mailer · Nodemailer setup for invites and reminders
server/configs/nodemailer.js - Inngest jobs · Event-driven email, webhook sync, and analytics processing
server/inngest/index.js
Data
Prisma schema and persistent storage
- Schema · Prisma schema for users, workspaces, members, projects, tasks, comments, and notifications
server/prisma/schema.prisma - PostgreSQL · Persistent collaboration data store
Integrations
Identity, email, and async job services
- Clerk · Authentication and organization context
- SMTP · Outbound mail transport
- Inngest · Background job orchestration and event handling
Connections 23
- main.jsx → App: boots · Entry mounts the app
- App → Pages: routes to · App composes route-level screens
- App → Components: uses · Shared UI is assembled from reusable components
- App → Store: provides · App is wrapped by shared Redux state
- Store → Slices: includes · Store combines workspace and theme slices
- Pages → Workspace UI: renders · Pages present the main workspace and project flows
- Components → Workspace UI: supports · Components implement dialogs, sidebars, analytics, and calendars
- Workspace UI → API client: calls · UI issues protected HTTP requests
- API client → server.js: requests · Client talks to the API server
- Clerk → Workspace UI: authenticates · Provides user and org context to the client
- server.js → Routes: mounts · Express app exposes resource routes
- Routes → Auth middleware: protects · Routes enforce workspace access
- Routes → Controllers: delegates · Route handlers forward to domain logic
- Controllers → Prisma client: reads/writes · Controllers persist and fetch data through Prisma
- Prisma client → Schema: uses · Prisma client is generated from schema
- Schema → PostgreSQL: stores · Schema maps collaboration entities to PostgreSQL
- Controllers → Mailer: sends · Business actions trigger email side effects
- Inngest jobs → Inngest: runs on · Background processing is driven by Inngest events
- Inngest jobs → Mailer: triggers · Jobs send reminders, invites, and updates
- Inngest jobs → Prisma client: aggregates · Jobs read persisted data for analytics processing
- Controllers → Inngest jobs: emits events · App activity feeds asynchronous workflows
- Clerk → Auth middleware: identifies user · Server validates Clerk-backed identity before access
- SMTP → Mailer: delivers · Outgoing mail is sent through SMTP