How amansinhaa110/codealpha_project_management_tool works
1. Overall shape
- This is a small full-stack Node.js monolith: one Express server handles HTTP requests, serves the browser assets, manages authentication/session state, and hosts the Socket.io realtime channel.
- The browser client is delivered from public/ and talks back to the same server for both standard requests and realtime events.
2. Main runtime boundary
- The backend runtime is Node.js + Express in server.js.
- The frontend is a static client in public/index.html, public/app.js, and public/styles.css.
- There is no separate frontend build pipeline or separate API service visible in the repo; the server is the central integration point.
3. Persistence layer
- database.js is the dedicated data-access boundary.
- The app uses a local SQLite database file, pmo.db, via better-sqlite3.
- This suggests synchronous, embedded persistence rather than a remote database service, which keeps deployment simple and local-state oriented.
4. Authentication and session management
- The README indicates bcryptjs for password hashing and express-session for session persistence.
- That means the app likely authenticates users server-side, stores session identifiers in cookies, and authorizes access to PMO features using session state rather than token-based auth.
- Authentication is therefore part of the server boundary, not the client.
5. Realtime collaboration path
- Socket.io is the key realtime subsystem.
- The server likely publishes project/task changes through socket events so connected clients receive immediate updates without polling.
- This creates a second communication channel alongside normal HTTP: browser-to-server for setup/actions, and server-to-browser for broadcast updates.
6. Client responsibilities
- public/app.js is the main browser-side control layer.
- It likely handles page interactions, form submissions, socket connection setup, and DOM updates when collaborative state changes.
- public/index.html provides the UI shell, while public/styles.css defines presentation only.
7. Server responsibilities
- server.js is the orchestration layer that ties together Express routes, session middleware, authentication logic, Socket.io setup, and database operations.
- It also serves the static frontend files, so the same process owns both the UI delivery and backend business logic.
8. Data flow: login/session
- User credentials enter through the browser UI.
- The server validates them against stored user records, compares hashed passwords, and creates a session.
- Subsequent requests and socket connections rely on that session context to identify the user.
9. Data flow: project/task updates
- A user action in the browser triggers an HTTP request or socket message to the server.
- The server writes changes to SQLite through database.js.
- After persistence, the server broadcasts the update via Socket.io so other connected clients refresh their view.
10. Deployment and operational boundary
- The app is designed to run locally with npm start or node server.js on port 3000.
- Because the database is a file in the repo root, the system has a local embedded state boundary: app code and data live together.
- This makes the architecture easy to diagram as a single node hosting web, realtime, auth, and storage concerns.
11. Repository-level components to show in a diagram
- One box for Browser/UI (public/*)
- One box for Express/Socket.io server (server.js)
- One box for Data access (database.js)
- One box for SQLite file (pmo.db)
- One boundary for session/auth middleware sitting inside the server process
- Arrows for HTTP/static asset delivery, session-protected actions, and Socket.io broadcast updates
12. Architectural takeaway
- The repo implements a single-process collaborative app where persistence, authentication, and realtime coordination are centralized on the Node.js server, and the browser acts as a thin interactive client consuming both HTTP and socket-driven updates.
Main entry points: server.js Server app · app.js Client logic · database.js Data access · index.html UI shell
Components 8
Browser UI
Static frontend delivered by the Node server
- UI shell · Main page markup for the browser app
public/index.html - Client logic · Handles interactions, requests, and live updates
public/app.js - Styles · Presentation layer for the browser UI
public/styles.css
Node Server
Express app, auth, and realtime coordination
- Server app · HTTP server and process-level orchestration
server.js - Auth session · Password validation, login state, and session-backed access control
server.js - Realtime channel · Pushes updates to connected browsers
server.js
Local State
Embedded persistence and stored application data
- Data access · Repository boundary for reading and writing app data
database.js - SQLite DB · Local persistent application state
pmo.db
Connections 12
- Server app → UI shell: serves · Delivers the browser shell and static assets
- Server app → Client logic: serves · Delivers the browser client script
- Server app → Styles: serves · Delivers the stylesheet
- Client logic → Server app: HTTP actions · Sends user requests and form submissions
- Client logic → Realtime channel: connects · Opens the Socket.io client channel
- Server app → Auth session: uses · Applies login and session checks to requests
- Auth session → Data access: reads/writes · Validates users and persists session-related state
- Server app → Data access: uses · Coordinates data operations through the data layer
- Data access → SQLite DB: persists · Stores application records in the local SQLite file
- Server app → Realtime channel: broadcasts · Emits collaboration updates after changes
- Realtime channel → Client logic: pushes · Delivers live updates to connected clients
- Auth session → Client logic: gates · Restricts client actions to authenticated sessions