How ankitcodesju/rollcall works
1. High-level shape
- RollCall is a two-tier MERN-style application: a Next.js frontend talks to an Express/Node backend, which persists data in MongoDB through model classes.
2. Frontend boundary
- The frontend lives in frontend/src/app and uses the Next.js App Router.
- Routes are organized by feature: login, register, dashboard, classes, class, notifications, plus nested routes for class detail and attendance views.
- Shared UI is minimal and centralized, with a Navbar component and global styling via TailwindCSS.
3. Frontend-to-backend communication
- frontend/src/utils/api.js is the main client-side integration point, implying a centralized API wrapper for calling the backend.
- The frontend is primarily a presentation and interaction layer; business rules such as class creation, attendance updates, and notifications are handled on the server.
4. Backend entry points
- The backend has both backend/app.js and backend/server.js, indicating an Express app setup separated from process bootstrapping/deployment concerns.
- backend/src/config/db.js handles MongoDB connection setup, and check_db.js is a utility for verifying database connectivity.
5. Backend domain modules
- The API is split by domain under backend/src/controllers and backend/src/routes:
- user for auth/user flows
- class for class management and membership workflows
- attendance for attendance matrix updates
- notification for in-app alerts
- This is a classic REST structure: route layer receives requests, controller layer applies logic, model layer persists state.
6. Persistence layer
- backend/src/models contains the core data entities:
- User
- Class
- ClassRecord
- Attendance
- Notification
- The presence of separate ClassRecord and Attendance models suggests the app distinguishes between roster/join-state data and per-date attendance events.
7. Auth and access control
- backend/src/middlewares/authMiddleware.js is the main security boundary.
- The README indicates JWT authentication, so authenticated requests likely pass through this middleware before reaching protected class/attendance/notification endpoints.
8. Key functional data flows
- Login/Register: frontend auth pages call the user API, backend issues/validates identity, and the frontend stores session state.
- Class management: teachers create/manage classes; students join via class codes or requests; class state is stored in MongoDB.
- Attendance tracking: the class attendance page drives updates into attendance-related models through the backend.
- Notifications: class membership and leave/approval events create persistent notification records, which the frontend reads from the notifications page.
9. Information architecture on the frontend
- The UI separates teacher/student workflows into different screens rather than one monolithic dashboard.
- dashboard is the landing/summary area, classes/create handles class creation, classes/[id] and classes/[id]/attendance handle class detail and attendance management, and notifications surfaces system messages.
10. Operational/deployment boundary
- backend/vercel.json shows the backend is prepared for Vercel deployment, which is notable because Express is being run in a serverless-friendly shape.
- The project’s live demo is also hosted on Vercel, so the runtime boundary is likely: Next.js frontend on Vercel + API backend deployed separately, both sharing MongoDB as the system of record.
11. What is not present
- There is no evidence of a separate queue, cache, message broker, or WebSocket layer in the repository tree.
- So the architecture is best understood as request/response REST APIs + persisted notifications, not as a streaming or event-driven distributed system.
12. How to draw the diagram
- Draw three main boxes: Next.js client, Express API, and MongoDB.
- Inside the API box, split into users, classes, attendance, and notifications, with JWT auth middleware guarding protected routes.
- Show the frontend pages calling the API through a shared api utility, and show all domain data flowing into MongoDB through the model layer.
Main entry points: app.js Express app · app Next app · api.js API client · models Data models
Components 17
Frontend
Next.js App Router client and shared UI.
- Next app · App Router entry and page hierarchy.
frontend/src/app - Auth pages · Login and registration screens.
frontend/src/app/login/page.js - Dashboard · Summary landing area after sign-in.
frontend/src/app/dashboard/page.js - Classes · Class list, creation, detail, and attendance views.
frontend/src/app/classes - Notifications · In-app notification inbox.
frontend/src/app/notifications/page.js - Navbar · Shared top-level navigation UI.
frontend/src/components/Navbar.js - API client · Central frontend integration point for backend calls.
frontend/src/utils/api.js - Global style · App-wide Tailwind and base CSS.
frontend/src/app/globals.css
Backend
Express API, auth, and MongoDB persistence.
- Server boot · Process startup and app wiring.
backend/server.js - Express app · Middleware and route composition.
backend/app.js - DB config · MongoDB connection setup.
backend/src/config/db.js - Auth guard · JWT-protected request boundary.
backend/src/middlewares/authMiddleware.js - User API · Authentication and user flows.
backend/src/controllers/userController.js - Class API · Class creation, membership, and class detail flows.
backend/src/controllers/classController.js - Attendance API · Attendance matrix and update flows.
backend/src/controllers/attendanceController.js - Notification API · Notification creation and retrieval flows.
backend/src/controllers/notificationController.js - Data models · User, Class, ClassRecord, Attendance, and Notification entities.
backend/src/models
Connections 23
- Next app → Auth pages: routes · App Router serves auth screens.
- Next app → Dashboard: routes · App Router serves dashboard screen.
- Next app → Classes: routes · App Router serves class workflows.
- Next app → Notifications: routes · App Router serves notifications screen.
- Next app → Navbar: uses · Shared navigation appears across pages.
- Next app → Global style: styles · Global styling is loaded by the app.
- Auth pages → API client: calls · Auth pages use the shared API client.
- Dashboard → API client: calls · Dashboard fetches backend data through the client wrapper.
- Classes → API client: calls · Class views use the shared API client.
- Notifications → API client: calls · Notifications screen reads from the backend.
- API client → Express app: HTTP · Frontend client talks to the Express API.
- Server boot → Express app: starts · Server bootstrap launches the Express app.
- Express app → Auth guard: protects · Protected routes pass through JWT auth middleware.
- Express app → User API: mounts · User routes/controllers handle auth and identity.
- Express app → Class API: mounts · Class routes/controllers handle roster and class state.
- Express app → Attendance API: mounts · Attendance routes/controllers handle attendance updates.
- Express app → Notification API: mounts · Notification routes/controllers handle alerts.
- User API → Data models: persists · User flows read and write MongoDB entities.
- Class API → Data models: persists · Class workflows store class and record data.
- Attendance API → Data models: persists · Attendance updates are written to MongoDB.
- Notification API → Data models: persists · Notifications are stored and retrieved from MongoDB.
- DB config → Data models: connects · Mongo connection underpins the model layer.
- Server boot → DB config: initializes · Server startup initializes database connectivity.