How ashishb20/recallops works
1. Overall shape
- RecallOps is a two-tier full-stack app: a React/Vite frontend in client/ and a Node/Express API in server/.
- The architecture is centered on a single domain: learning tasks managed with 1-4-7 spaced repetition scheduling.
2. Frontend presentation layer
- The UI lives in client/src/ and is organized by pages (Dashboard, Login, Register, NotFound) and reusable components (TaskCard, TaskDropdown, AddTaskModal, EditTaskModal, Stats, Timer, Navbar, Footer, ToastContainer, ErrorBoundary).
- Dashboard is the main workspace where users view, create, edit, and review tasks.
- Login and Register form the public entry path, while NotFound handles unknown routes.
3. Client state and auth boundary
- AuthContext plus the useAuth hook provide app-wide authentication state.
- This is the client-side boundary that decides whether a user sees the learning dashboard or the auth screens.
- The presence of ErrorBoundary and toast components suggests the UI is designed to handle runtime failures and async feedback gracefully.
4. Client service layer
- client/src/services/api.js is the HTTP access layer used by the rest of the frontend.
- authService.js and taskService.js isolate API calls from UI code, which keeps pages/components focused on rendering and interaction.
- This creates a clean separation: components manage user interaction, while services manage server communication.
5. Backend API layer
- The server is an Express app with route modules in server/routes/ and business logic in server/controllers/.
- Auth and task operations are split into separate endpoints, reflecting two main backend concerns: identity and learning-task lifecycle.
- server/server.js is the API entry point and likely wires middleware, routes, and database startup.
6. Authentication flow
- authController.js, authRoutes.js/auth.js, and middleware/auth.js indicate token-protected API access.
- The likely flow is: user registers/logs in on the frontend → backend validates credentials → client stores auth state → subsequent task requests include auth credentials and pass through middleware.
- This boundary separates public auth endpoints from protected task management endpoints.
7. Task and spaced-repetition domain
- Task.js is the core domain model and represents the learning item being reviewed.
- taskController.js handles task CRUD and review progression.
- utils/dateHelper.js is important because it likely computes review timing based on the 1 day / 4 days / 7 days schedule described in the README.
- That means the backend owns the authoritative scheduling logic, not the client.
8. Persistence layer
- config/db.js connects the application to its database, and the User and Task models indicate a MongoDB/Mongoose-style persistence layer.
- Users and tasks are stored separately, with tasks likely linked to the authenticated user.
- This creates a clear data boundary: the frontend never talks to the database directly; all persistence goes through controllers and models.
9. User-facing task workflow
- The main loop is: create task → review task when due → update its repetition stage/date → display updated stats.
- AddTaskModal and EditTaskModal handle task authoring; TaskCard and TaskDropdown support browsing and action menus; Timer suggests time-based review or focus behavior; Stats summarizes progress.
- This workflow is what turns the app from a generic task manager into a spaced-repetition learning tool.
10. Routing and navigation
- On the client, page-level routing likely switches between dashboard and auth views.
- On the server, route modules map HTTP paths to controller actions for auth and tasks.
- The architecture is therefore split into UI routing on the frontend and REST-style API routing on the backend.
11. Styling and runtime stack
- The frontend uses Vite, React, Tailwind/PostCSS, and ESLint tooling.
- vercel.json suggests the client is prepared for Vercel deployment.
- The backend is a standard Node.js service with package management isolated from the client, which implies separate build/deploy concerns for frontend and API.
12. Diagramming guidance
- A good architecture diagram should show three main layers: React UI, Express API, and database/persistence.
- Within the API, highlight two domains: authentication and task scheduling/review logic.
- The most important data flow is the review schedule update: frontend action → task API → controller/model/date helper → persisted task with next due date → refreshed dashboard/UI state.
Main entry points: App.jsx App shell · Dashboard.jsx Dashboard · AuthContext.jsx Auth state · taskController.js Task controller
Components 21
Client
React/Vite frontend and UI state
- App shell · Top-level client composition and routing
client/src/App.jsx - Auth state · Global authentication boundary for the UI
client/src/context/AuthContext.jsx - Dashboard · Main workspace for creating, reviewing, and editing tasks
client/src/pages/Dashboard.jsx - Login · Public sign-in screen
client/src/pages/Login.jsx - Register · Public account creation screen
client/src/pages/Register.jsx - Not Found · Fallback route for unknown paths
client/src/pages/NotFound.jsx - Task UI · Task cards, menus, and modal editing surfaces
client/src/components/TaskCard.jsx - Feedback UI · Toast, error boundary, stats, and timer presentation
client/src/components/ToastContainer.jsx - API services · HTTP access layer used by the frontend
client/src/services/api.js - Auth service · Client auth API wrapper
client/src/services/authService.js - Task service · Client task API wrapper
client/src/services/taskService.js
Server
Express API and domain logic
- API server · Express bootstrap and middleware wiring
server/server.js - Auth routes · Authentication endpoints
server/routes/authRoutes.js - Task routes · Task and review endpoints
server/routes/tasks.js - Auth controller · Credential validation and user session handling
server/controllers/authController.js - Task controller · Task CRUD and review progression
server/controllers/taskController.js - Auth middleware · Protects authenticated API access
server/middleware/auth.js - Date helper · Spaced-repetition timing logic
server/utils/dateHelper.js
Data
Database connection and persisted models
- DB config · Database connection bootstrap
server/config/db.js - User model · Persisted user identity record
server/models/User.js - Task model · Persisted learning task and review state
server/models/Task.js
Connections 30
- App shell → Auth state: provides auth · App wraps the UI in authentication state
- App shell → Dashboard: routes to · Authenticated workspace view
- App shell → Login: routes to · Public sign-in view
- App shell → Register: routes to · Public registration view
- App shell → Not Found: fallback · Unknown route handling
- Dashboard → Task UI: uses · Dashboard renders task interactions
- Dashboard → Feedback UI: uses · Dashboard surfaces stats, toasts, and timers
- Login → Auth service: calls · Login submits credentials through auth service
- Register → Auth service: calls · Registration submits credentials through auth service
- Dashboard → Task service: calls · Dashboard loads and mutates tasks through task service
- API services → Auth service: wraps · Shared HTTP layer under auth calls
- API services → Task service: wraps · Shared HTTP layer under task calls
- Auth service → Auth routes: HTTP auth · Client authentication requests hit auth endpoints
- Task service → Task routes: HTTP tasks · Client task requests hit task endpoints
- API server → Auth routes: mounts · Express mounts auth routes
- API server → Task routes: mounts · Express mounts task routes
- Auth routes → Auth controller: delegates · Auth routes pass work to the controller
- Task routes → Auth middleware: protects · Task access is authenticated
- Task routes → Task controller: delegates · Task routes pass work to the controller
- Auth controller → User model: reads/writes · User records are created and verified
- Task controller → Task model: reads/writes · Task records are created and updated
- Task controller → Date helper: computes due date · Review progression uses spaced-repetition timing
- Auth controller → DB config: uses db · Controllers operate through the database connection
- Task controller → DB config: uses db · Task persistence uses the database connection
- User model → DB config: stored via · User model persists through the shared DB connection
- Task model → DB config: stored via · Task model persists through the shared DB connection
- Auth state → Dashboard: gates access · Authenticated users reach the dashboard
- Auth state → Login: gates access · Unauthenticated users reach login
- Auth state → Register: gates access · Unauthenticated users can register
- Auth middleware → Auth controller: verifies token · Protected routes rely on auth verification