maipriyanshuhoooon/crud-app

1. Repository shape

- This is a two-part MERN application with a hard split between Backend/ and Frontend/.

- The runtime boundary is clean: the React SPA talks only to the Express API over HTTP, and the API talks to MongoDB through Mongoose.

- Top-level Dockerfile suggests the project is also intended to be containerized for deployment.

2. System boundary and main data flow

- Primary flow is: browser UI → axios → Express REST endpoints → Mongoose models → MongoDB Atlas.

- Responses come back as JSON and are used by the frontend to update global state and render task cards, modal views, and auth screens.

- Authentication is lightweight and client-driven in this repo: the frontend stores a user identifier in localStorage and sends it in a custom user header.

3. Backend bootstrap

- Backend/index.js is the server entry point.

- It loads environment variables, connects to the database, imports the Express app, and starts listening on the configured port.

- Backend/src/app.js is the Express composition layer: it applies middleware and mounts the API router under /api/v1.

4. Backend infrastructure and configuration

- Backend/src/db.config.js encapsulates the MongoDB connection via Mongoose.

- cors and JSON body parsing are enabled at the app level, which means the API is designed for cross-origin browser access from the Vite dev server.

- Environment configuration is externalized through .env so database credentials and port are not hardcoded.

5. Backend domain model

- Backend/src/model/user.model.js defines the user document shape used for registration and login.

- Backend/src/model/task.model.js defines the task document shape, including a reference back to the owning user.

- The task collection is the main business data store; most API operations are scoped to the authenticated user.

6. Backend API contract

- Backend/src/routes.js contains the application’s REST contract.

- It exposes endpoints for registration, login, profile retrieval, task listing, task creation, single-task fetch, update, and deletion.

- A custom auth middleware reads the user header, resolves the user, and places it on req.user so all task queries can be user-scoped.

- ObjectId validation is handled before database operations, which protects the API from malformed task IDs.

7. Frontend runtime and app shell

- Frontend/src/main.jsx mounts the React app into the Vite-served HTML shell.

- Frontend/src/App.jsx wires together routing, global context, and the common layout pieces like navbar and footer.

- The app is a single-page client, with page transitions handled by React Router rather than full browser reloads.

8. Frontend navigation and access control

- Frontend/src/layout/ProtectedLayout.jsx is the route guard for authenticated areas.

- If there is no stored user identifier, the layout redirects to /login; otherwise it renders nested routes.

- Public routes include login, registration, and the fallback error page; protected routes cover the dashboard and task creation.

9. Frontend state boundary

- Frontend/src/context/MainContext.jsx is the central client state layer for task data.

- It fetches the full task list, stores it in context, and exposes helpers for adding/removing tasks locally.

- This context is the main bridge between API responses and UI rendering, reducing prop drilling across the component tree.

10. Frontend API integration

- Frontend/src/utils/axiosClient.js is the HTTP client boundary.

- It sets the backend base URL and includes the stored user identifier in requests, which is how the frontend participates in the app’s auth mechanism.

- This file is important architecturally because it centralizes all backend communication settings.

11. Frontend pages and feature screens

- Frontend/src/pages/Dashboard.jsx is the main task overview; it reads from context and performs client-side filtering/search.

- AddTaskPage.jsx handles task creation, while loginPage.jsx and Register.jsx handle authentication flows.

- errorPage.jsx serves as the fallback route for unmatched paths.

12. Frontend task interaction pattern

- TaskCard.jsx is the compact list item view for a task.

- TaskView.jsx opens a modal and fetches the full task record on demand.

- TaskViewChild.jsx renders the read-only detail view and also handles deletion.

- TaskUpdateView.jsx switches the modal into edit mode and submits updates back to the API.

- This modal-based design keeps list rendering lightweight while deferring detailed fetch/edit operations until needed.

13. Frontend UI support components

- Navbar.jsx, Footer.jsx, Logo.jsx, LoaderButton.jsx, and LoaderComponent.jsx are shared UI primitives.

- They are not separate business subsystems, but they support consistent navigation, feedback, and layout across the SPA.

- Frontend/src/utils/constant.js appears to centralize category-to-style mapping, which keeps presentation rules out of feature screens.

14. End-to-end behavior

- A typical session starts with auth pages, moves into the protected dashboard, then uses the task modal to view, edit, or delete items.

- Create/update/delete actions are sent to the API; successful responses are reflected in the context state so the UI updates immediately.

- Search is client-side only, so it operates entirely within the React state layer without extra backend calls.

15. Technology choices that affect architecture

- Vite shapes the frontend development/runtime boundary, giving the SPA its own dev server on port 5173.

- Express and Mongoose define the backend service boundary on port 4500, with MongoDB Atlas as the external persistence layer.

- Nodemon, dotenv, and CORS are operational enablers rather than core business logic, but they materially support local development and browser-to-API communication.