harmannmahna/planify

1. Overall shape

- Planify is a two-tier MERN application: a React frontend talks to an Express API backend, and the backend persists users, tasks, points, and room state in MongoDB via Mongoose.

- The product boundary is clean: the frontend handles interaction and UI state; the backend owns authentication, business rules, and persistence.

2. Backend as the system of record

- backend/server.js is the entry point that likely wires Express middleware, routes, database connection, and deployment configuration.

- All durable application state lives here through MongoDB models, not in the browser.

3. Core backend domains

- models/User.js represents the authenticated user and appears to hold user-specific game state such as points and room ownership/progression.

- models/Task.js represents task records with fields for title, description, status, and priority.

- These models support the two primary product loops: task completion and room progression.

4. API surface

- routes/auth.js handles registration, login, and user-centric endpoints such as points or room-related user data.

- routes/tasks.js exposes task CRUD and completion flows.

- routes/room.js handles shop/purchase/room customization behavior.

- This routing split maps closely to the app’s functional areas and is the main backend decomposition.

5. Authentication and access control

- middleware/authMiddleware.js is the gatekeeper for protected routes, enforcing JWT-based access.

- The backend validates the token before allowing access to task, room, or user-state operations.

- This creates a server-side security boundary; the frontend does not own authorization.

6. Frontend shell and routing

- frontend/src/main.jsx boots the React app, and frontend/src/App.jsx likely defines top-level routing and layout composition.

- react-router-dom is used to separate public auth screens from protected application pages.

- components/ProtectedRoute.jsx is the client-side route guard that complements server-side JWT enforcement.

7. State management on the client

- frontend/src/app/store.js configures Redux Toolkit as the central state container.

- features/auth/authSlice.js manages login/register/session state.

- features/tasks/tasksSlice.js manages task data and task-related async operations.

- This keeps API-backed data and auth state consistent across pages and components.

8. Client-to-server data flow

- frontend/src/api/axios.js is the API boundary for HTTP calls to the backend.

- Pages and slices dispatch actions that call the Express routes through Axios, then update Redux state from responses.

- The main data loop is: user action in UI → Redux async request → API route → MongoDB update → response → store/UI refresh.

9. Primary user experiences

- pages/Login.jsx and pages/Register.jsx are the public entry points for account creation and sign-in.

- pages/Dashboard.jsx is the main working surface for tasks, Pomodoro, points, and room preview.

- pages/Room.jsx is the dedicated room/shop experience for buying and placing items.

10. Dashboard feature composition

- components/Pomodoro.jsx is a self-contained productivity timer that contributes points when sessions complete.

- components/TaskFormModal.jsx and components/TaskCard.jsx support task creation and task lifecycle operations.

- components/Navbar.jsx provides global navigation and likely surfaces user state such as points or session status.

- The dashboard is therefore a composition of several feature widgets rather than a monolithic page.

11. Gamification loop

- Completing a task or a Pomodoro session awards points, which are stored persistently in MongoDB.

- Those points are then spent in the room/shop flow to unlock or place items.

- This creates a closed loop between the task domain and the room domain, with the user record acting as the shared ledger.

12. Frontend styling and build tooling

- The frontend uses Vite for development/build, Tailwind CSS for styling, and PostCSS/Tailwind config files for CSS processing.

- The public/ and index.html structure indicates a standard single-page app deployment model.

- Styling is heavily theme-driven, with a pixel-art/dark UI aesthetic.

13. Deployment/runtime boundary

- The backend runs as a Node/Express service and the frontend as a static SPA build, both deployed on Render per the README.

- MongoDB Atlas is the external persistence service, so database connectivity is an architectural dependency rather than local state.

- The repo’s .env files show that secrets and connection details are environment-driven, not hard-coded.

14. Key architectural takeaway

- The app is organized around three persistent domains: identity, tasks, and room ownership/progression.

- The backend centralizes validation and persistence, while the frontend focuses on interaction, route protection, and real-time user experience.

- If you draw the architecture, the most important arrows are: browser → Axios → Express routes → Mongoose models/MongoDB, with JWT auth protecting the path.